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Két számmal ezelőtt írtam a 
szotar.kiskapu.hu új bővítéseiről. 
Szinte szóról szóra megismételhetem 
magam: , Igaz, még mindig csecsemő- 
korát éli, de a tartalma folyamatosan 
bővül, és igyekszünk a jelzett hiányos- 
ságokat is javítani benne". Igyekez- 
tünk lehetővé tenni mindenki számára, 
hogy a hiányzó szavakat könnyen el 
tudja küldeni, illetve új szerkezetet 
adtunk a letölthető változatnak, remé- 
lem, így könnyebben használható. 
lermészetesen a szótár hatékonysága 
nagymértékben azon múlik, hogy 
milyen szószedettel dolgozik. Nagyon 
sok olyan szóval kell megküzdenünk, 
amelyre még nincs jó magyar fordítás, 
és folyamatosan keresnünk kell a határ- 
vonalat: mit tudunk lefordítani és mit 
nem. Hiába születik több fordítás egy 
angol szóra, ha azt a szakma nem képes 
(vagy nem akarja használni). Az egyik 
olvasó például az alábbiakat írta: 


Szerény véleményem szerint nem kellene 
a magyarítást túlságosan erőltetni, ha az 
az érthetőség rovására meg. Például 
cluster 7 géptelep. Többször neki kellett 
ugranom a mondatnak, mire megértettem, 
mi is lehet az a géptelep. 


Nem mernék nyíltan állást foglalni, 
hogy ki melyiket érti jobban. lapasz- 
talatom szerint ugyanis az emberek 
többsége (ideértve számos rendszer- 
gazdát is) könnyedén egy kalap alá 
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veszi a cluster, array, farm, de még 

a stack szavakat is. Mondják, mind 
ugyanazt jelenti: , Sok izé együtt. 

És különben is, ha szakemberrel beszé- 


lek, úgyis angolul használjuk, nem?" 
De, angolul, és ugyanúgy pontatlanul. 
Az ember hajlamos azt hinni, hogy 

az angol nyelvterületeken élő informa- 
tikusok pontosan tudják, mi micsoda. 
Nos, fityfenét. 

Azt viszont el kell ismerni, hogy egy- 
egy cikk fordítása gyakran sokkal 
nehezebb feladat, mint az eredeti 
angol nyelvű szöveg megértése. Ez 
még akkor is így lehet, ha angolul 

csak keveset értünk. Például a 30. olda- 
lon kezdődő szakcikk, a , Reiser4: 
hatékonyan gyorstárazó fák tervezése" 
így, többszöri átolvasás után is — biztos 
vagyok benne - tele van félreérthető 
fordításokkal. Ez egyrészt betudható 

a fordításnak, másrészt más okok 15 
megbújnak a háttérben. Olyan szakmai 
különbségekre gondolok, mint például 
a B és B-t fák szerkezete (különböző 
iskolákban különböző módon tanítják). 
Röviden összefoglalva: sok munka 

áll még előttünk, míg kialakítunk egy 
egységes, rögzített nyelvezetet, és 
könnyen lehet, hogy ez csak azokon 

a területeken történhet meg, ahol a 
szakma már egységes és letisztult! 


accessibility — kisegítő lehetőségek 
(lásd ott) 

applet — kisalkalmazás 

átirányítás (redirecting) — egy címre 
érkező kérelemnek (akár szolgáltatás, 
akár adatküldés stb.) önműködően 
egy másik címre történő küldése. 
consistent — következetes, egységes 
szerkezetű, szerkezeti sérülésektől 
mentes 

constructor -— létrehozó 

destructor — megszüntető 

engine — motor 

folyamat -— process 

forwarding - továbbítás 

kisalkalmazás (applet) — olyan önálló 
programocska, amely képes valamilyen 
futtatási környezetbe beágyazódni. 
Például a weboldalakba, vagy a grafikai 
alkalmazásokba ,beágyazódó" progra- 
mocska ilyen. A fordítás sajnos hosszú, 
de eddig nem találtunk jobbat. 
kisegítő lehetőségek (accessibility) 

— a felhasználói felület részeinek hasz- 
nálatát (megjelenítés, bevitel stb.) 
segítő kiegészítések, például csökkent 
képességű (vak, halláskárosult stb.) 

-— felhasználók számára. Sajnos nem 
találtunk rá jobb fordítást. 

konzisztens - lásd: consistent 

létrehozó (constructor) -— az a függvény, 


vagy programrész, amely egy változót 
(objektumot stb.) hoz létre, alapér- 
tékeit, kapcsolatait beállítja. 
megszüntető (destructor) — az a függ- 
vény vagy programrész, amely egy 
változó (objektum) megszűntetésekor 
elvégzi a szükséges feladatokat (kap- 
csolatok, függőségek bontása, terü- 
letek felszabadítása stb.). 

motor — engine 

namespace — névtér 

névtér (namespace) -— olyan terület, rész 
vagy egység, amelyen belül csak az 
adott névtéren belül látható változók 
hozhatók létre. 

overloading - túlterhelés (lásd ott) 
portable - környezettől függően jelent- 
het átültethetőt vagy hordozhatót. 
process — folyamat 

redirecting - átirányítás 

remote login - távoli bejelentkezés 
távoli bejelentkezés (remote login) 

— az adott számítógépre nem közvet- 
lenül történő (például nem a géphez 
kapcsolt első billentyűzet/monitor 
pároson) történő bejelentkezés. 

TCO (Total Cost of Ownership) 

— Teljes Birtoklási Költség: az összes 
olyan költség, amely egy adott gép 
(alkatrész, hálózat stb.) megvásárlása 
és üzemeltetése során felmerül. Ide 
tartozik például a karbantartási díj, 

a követési díj, a kötelező szervizek, 
az alkatrészkopás, az üzemben tartó 
személyzet költsége, az áramköltség, 
az elfoglalt terület bérleti díja. 
továbbítás (forwarding) — valamilyen 
(általában egy másik gép által biztosí- 
tott) szolgáltatás elérhetővé tétele az 
adott szolgáltatáson belül. Például 
SSH-val távoli bejelentkezés közben 
az SSH az X11-csomagokat is továbbít- 
hatja, ezáltal grafikus programokat is 
futtathatunk. 

túlterhelés (overloading) — programo- 
zási nyelvekben (például C-t --) az a 
képesség, hogy ugyanazon a néven 
több változó (függvény stb.) is szere- 
pel, és a kódban a használat módjától 
függően mindig a megfelelő változó 
(függvény) kerül felhasználásra. 
Például van két £ nevű függvényünk, 
az első egy, a második két éréket vár. 
Ha a programban egy értéket adunk 
át £-nek, az első függvényt hívjuk 
meg, de ha kettőt, akkor a második 
függvényt. Még nem tisztázott a for- 
dítás sorsa, bár szó szerint és értelmi- 
leg is helyes, mégis, továbbra is kere- 
sünk más fordításokat is. Javaslatként 
felmerült a kiterjesztés is. 
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Szy György 

a Linuxvilág főszerkesztője, 

a Kiskapu Kiadó vezetője. 
Mindenki levelét örömmel 
várja a következő levélcímen: 
Szy. Gyorgy Olinuxvilag.hu 


Az egyensúly keresése 
Megjelent egy hír, miszerint 
a Microsoftot 512 millió 
dollár kártérítés megfize- 
tésére ítélték. Amikor ezt 

a hírt olvastam, Shan-Iung 
Hsu fengshui-mester taní- 
tásai jutottak eszembe. 
Amikor Magyarországon 
járt, előadása felütéseként 
a mester azt igyekezett 
megértetni velünk, hogy 

a fengshui nem arról szól, 
hogy a szobámat hogyan 
rendezzem be, hogy hajt- 
sam le a tojodában az ülő- 
deszkát, vagy hogy ne rakjak tükröt 

az ajtóval szembe. Ezek csak következ- 
mények. Mint amilyen következménye 
a náthának a rengeteg taknyos zsebken- 
dő. lanítása szerint az erőket kell meg- 
értenünk. Az erők áramlanak, egyen- 
súlyra törekszenek, és folytonosan 
hatnak egymásra, és ezek a hatások 
előbb-utóbb körbeérnek. 

A fejlődés során a számítástechnika vilá- 
ga egyszer eljutott egy görcsös állapot- 
ba. A hatalom néhány óriásvállalat 
kezében összpontosult, a megoldások 
drágák, nehezen hozzáférhetőek voltak. 
Ekkor néhány kishal nagyon ügyesen 
elcikázott a nagyok mellett, és új len- 
dületet adott — új típusú erőket hozott 

a piacra. Ilyen kishal volt a Microsoft is. 
Később az új erő képviselője világcéggé 
nőtte ki magát, szép lassan ugyanazokat 
a célokat tűzve maga elé, mint egykor 
legyőzött elődje. És megszülettek az új 
kishalak. Ezek a kishalak mára elcikáz- 
tak a mai óriások mellett. És utána? 

És utána ők is elkezdtek úszni a korábbi 
kishalak céljaihoz kísértetiesen hason- 
lító célok felé. 

De nézhetjük más szemszögből is. 

Az emberek szeretnek harcolni. Nem 
vallják be, de egyszerűen nem bírják 
elképzelni a békés egyensúly állapotát. 


Harcolni kell. Harcolni kell az óriások 
ellen, ha óriás vagy, a kishalak ellen, 
harcolni kell a fejőstehénért, aki évente 
fizeti a jogdíjat, ha fejőstehénnek érzed 
magad, harcolnod kell a szabadságért, 
ha szabad vagy, harcolnod kell mások 
jogaiért, ha jogaid vannak, harcolnod 
kell a jogdíjért, ha ingyen akarod a világ- 
nak adni a terméked, harcolnod kell az 
ingyenességért. Úgy látszik, ha valami- 
nek értéke van, akkor azért harcolni kell. 
És, természetesen, ellene is. 

Az erők oldaláról nézve ez egyszerű: 

ha valami kitér az egyensúlyból, a másik 
oldalt rántja maga felé. Ha valaki világ- 
uralkodó akar lenni, szabadságharco- 
sokat követel ki a világtól. Ha valaki 

fel akarja szabadítani az egész világot, 
zsarnokok bölcsőjét teremti meg. Fontos 
tehát, hogy tisztában legyünk az 
erőkkel. És természetesen a célokkal. 
Mert a célok is folyamatosan változnak. 
Az egyik nap még azon dolgozunk, 
hogy működjön a rendszer, a másikon 
pedig arra ébredünk, hogy valaki jog- 
díjat akar beszedni rá. Mint ahogy az 
üres lemezekre is jogdíjat fizetünk 
manapság. Ha úgy nézzük, ennek is 
megvan a maga előnye. Az ember már 
nyugodtan mondhatja, hogy a lemez 
csupán házi másolata az egykor meg- 
vásárolt hanglemeznek. Még a jogdíjat 
is megfizettük. 

Ebben a nagy kavarodásban az ember 
csak kapaszkodik, és reméli, hogy a sok 
őrültnek - akik például azon civakod- 
nak, hogy eredetileg melyikőjük találta 
fel a mondatvégi pontot (Amerikában 
erre is jogvédelmet akartak bejegyez- 
tetni) — egymást való perelgetése közben 
valamelyik hatóság nem dönt úgy, 
hogy a születése után törvénytelenül 
sírt fel, ezért pedig súlyos bírságot kell 
fizetnie. De ebben az esetben a Római 
Egyház perelné be a hatóságot, hogy 
jogdíj nélkül alkalmazza az eredendő 
bűn elméletét. 
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, 
Programvadászat 
öngészők hada áll rendel- 

kezésre Linux alatt — mostani 
B CD-mellékletünkön a legújabb 

és , legfontosabb" böngészőket 
adjuk közre. Ez természetesen 


mindenkinek más és más: akad, aki a 
Mozillát, a Netscape-et vagy az Operát 
kedveli. Akik KDE-felületet használnak, 
azok nagy része a Kongueror böngészőt 
részesíti előnyben, ezért mi megkísér- 
lünk mindenkinek a kedvében járni. 


Firebird 

Mozilla-alapokon nyugvó böngésző, 

ez azonban tényleg csak egy böngésző 
felesleges sallangok nélkül, számos más 
sallanggal viszont kiegészítve, ami segít- 





heti a böngészést. Böngészőnek kiváló. 
A Bongeszok/Mozilla Firebird könyvtár- 
ban találhatnak rá az érdeklődők. 


Opera 7.11 

lermészetesen a legfrissebb megbízható 
Opera böngésző sem maradhatott ki a 
sorból -— a szokásos formátumokban 
akadhatunk rá a korongon (rpm, deb, 
tar.gz). Az Opera még mindig csekély 
erőforrásigényével tűnik ki a többi 
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, memóriafaló" böngésző közül. Gyors, 
megbízható és a legtöbb akadályt, ami 
az interneten megtalálható, könnyedén 
veszi. Egyedüli idegesítő vonása az a 
bizonyos reklámcsík a jobb felső sarok- 
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ban, ami eltüntethető ugyan, de ezért 
fizetnünk kell. 

Megtalálható a Bongeszok/Opera 
könyvtárban. 


Netscape 7.1 

Hosszú fejlesztői munka után végre 
megjelenhetett a Mozilla 1.4, ebből 
egyenesen következik, hogy a Netscape 
is fejlesztett aböngészőjén. Szerencsére 
a híresztelésekkel ellentétben nem az 
1.2-es Mozilla lett ennek a csomagnak az 
alapja, hanem a legfrissebb 1.4-es. 
Korongunkon a hálózati és a teljes 
telepítőkészlet is megtalálható a 
Bongeszok/Netscape könyvtárban. 


Mozilla 1.4 

Mint fentebb már írtam, a Mozilla 1.4-es 
változata hosszú fejlődés után jelent 
meg. Nagyszámú újdonságot és hibaja- 
vítást követően 2003. június 30-án adták 
ki a fejlesztők. lapasztalataim szerint 
gyorsabb, mint az elődei voltak. Megta- 
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lálható a Bongeszok/Mozilla könyvtár- 
ban, mind telepíthető, mind forráskód 
formában. 


Mozilla 1.5a 

A böngészők legfiatalabbja, a , felnö- 
vekvő nemzedék , a következő fejlesztői 
Mozilla-változat. Csak ínyenceknek, 
fejlesztőknek vagy elszántaknak aján- 
lott. A Bongeszok/Mozilla könyvtárban 
helyeztük el. 


OpenOffice.org 1.1RC3 


Az OpenOffice.org-csapat is gőzerővel 
fejleszti csomagját — meg is lett az ered- 
ménye a rengeteg befektetett munká- 
nak! Gyorsabb és kevésbé nyűgös prog- 
ramot kaptunk, bár ez még csak az 
RC3-as kiadás, de már nagyon közel 











vagyunk a célhoz. Sokkal jobbak lettek 
a Microsoft-formátumok szűrőt, vala- 
mint PDE SWE DocBook formátumok 
beolvasására is képes. 

A CD-n az OpenOffice.org könyvtárban 
helyeztük el, vállalkozó és a progra- 
mozáshoz kedvet érző olvasóinknak 


forráskódban is közreadjuk. 


PostgreSOL 

Az általam igen kedvelt PostgreSOL 
legfrissebb, 2003. július 29-én megjelent 
7.3.4-es változata is helyet kapott. Ennek 
a forráskódját adjuk közre, hogy min- 
denki a saját szájízének megfelelően 
fordíthassa le. Minden PostgreSOL- 
használónak javasolt a frissítés, különös 
tekintettel a 7.3.3-as változatot futtatók- 
nak. A 7.3-as bármely alváltozatról 
frissítőóknek nem kell a dump-reload 
párost végrehajtania. 

Megtalálható még a 7.4betal-es változat 
forráskódja is, de mivel ez nem meg- 
bízható változat, csak ,guruknak" aján- 
lott. A korong PostgreSOL könyvtárában 
találhatóak. 


2.6.0-test3 


A címből is kiderül, hogy a 2.6-os soro- 
zatú rendszermag teszt3-as változata 
került fel a korongra. Seregnyi hibaja- 
vítás után egy még mindig csak próbál- 
gatásra és ismerkedésre alkalmas rend- 
szermagot kapunk, erre a feladatra 
azonban kiválóan megfelel, így amikor 
a végleges 2.6.0-változat megjelenik, 
nem fog meglepetésként hatni ránk 

a sok újdonság. 


Magazin 

A szokásos, magazinhoz tartozó anya- 
gok kaptak itt helyet, minden cikknél 

a cím mellett kis CD-vel jelezzük, ha a 
korongon hozzátartozó anyag található. 
E havi anyagaink közül a wxWindows- 
hoz tartozó csomagoknak és egyéb 
hasznos dolgoknak jut a legtöbb hely. 


Csontos Gyula 
(Csontos.Gyulaolinuxvilag.hu) 

A Linuxvilág szakmai és 
CD-szerkesztője. Szabadidejében 
szívesen mászik hegyet és 
kerékpározik. 


Aldásuk rá 
Az IEEE után a ZigBee Alliance — háló- 
zati termékeket gyártó cégek nonprofit 
egyesülése -— is szabványként fogadta 
el a 802.15.4-es 
jelzésű szabály- 
gyűjteményt. 
A 802.15.4 megbízható, biztonságos és 
kis energiafelhasználással végzett távoli 
felügyeletet és alkalmazásvezérlést tesz 
lehetővé vezeték nélküli hálózatokon. 
A szabvány az ISO OSI modell alsó két 
rétegét (fizikai és közeghozzáférés) fedi 
le, a megbízható csomagtovábbítást 
visszaigazolásokkal, hibajavítással, fon- 
tossági sorrend felállításával biztosítja, 
illetve a frekvenciaváltások levezérlé- 
sére is alkalmas is. A 24 GHz-es és a 
868/915 MHz-es frekvenciákat egyaránt 
lefedi, így világszerte számos távirányí- 
tási feladathoz lehet majd alkalmazni, 
nemcsak számítógépes környezetben, 
de például központilag vezérelhető 
háztartások kiépítéséhez is. 
2 http:/www.zigbee.org 


Legénykedő 5CO Group 
Sokan várják érdeklődéssel a SCO 
Grup által az IBM ellen indított peres 
eljárás végét. Amennyiben a bíróság 
igazat ad a SCO Groupnak, és megál- 
lapítja, hogy az azóta jogi ellentáma- 
dást is indított IBM 

adna jogtalanul épített be 

OnStagjó unixos megoldásokat 
a Linuxba, akkor az 

összes üzleti célból fenntartott Linux- 
kiszolgálón módosításokat kell majd 
végrehajtani. Meg kell ugyanis keresni 
minden olyan kódrészletet, amely a 
SCO szellemi tulajdonát képezi, és a 
linuxos közösség által készítettre le 
kell cserélni — elvileg. 
Ezt kézzel nyilván senki sem szeretné 
végigcsinálni — legalábbis az Aduva Inc. 
részéről így gondolják. A cég OnStage 
és SoundCheck néven két terméket for- 
galmaz, mindkettő a linuxos kiszolgálók 
felügyeletének megkönnyítését szol- 
gálja. Az utóbbi ingyenesen is elérhető, 
és amennyiben a bírósági eljárás a világ 
nagyobbik részére nézve kellemetlenül 
ér véget, akkor a cég egy külön változa- 
tot fog készíteni belőle, amely a kisebb- 
nagyobb hibák mellett a SCO Group 
által jegyzett kódrészletek azonosítására 
is alkalmas lesz. 
lermészetesen, ha valaki nem akar ilyes- 
mivel vacakolni, élhet a SCO Group 
gáláns ajánlatával is, és megvásárolhatja 
a kérdéses kódrészletek használatának 
a jogát. A SCO Intellectual Property 
License for Linux a unixos kódok 
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bináris formában való használatára 
jogosít fel, ahogy azok a Linux-terjesz- 
tésekben megtalálhatók. Így a 2.4-es 
vagy 2.5-ös változatú rendszermagot 
használók, miközben a Linux-terjesz- 
tésekre vonatkozó GPL szerződés fel- 
tételeit is maradéktalanul betartják, 
megszabadulhatnak attól a nyomasztó 
gondolattól, hogy esetleg jogtalanul 
futtatják gépükön a SCO által birtokolt 
kódrészleteket. A SCO - október 15-ig 
bevezető áron — mindössze 699 dollárt 
kér a használati jog megadásáért; ez az 
ár természetesen egyetlen processzorra 
értendő. A több processzorral felszerelt, 
beágyazott vagy asztali rendszerekhez a 
SCO hamarosan további megoldásokat 
is ki fog dolgozni. 

2 http:/www.aduva.com/soundcheck 
2 http:/www.sco.com/scosource 


Dugd össze, és... 

A Canon i560 jelzésű nyomtatója az első 
olyan tintasugaras nyomtató, amely a 
PictBridge megoldás révén -— a gyártó- 
tól függetlenül — közvetlenül a fényképe- 
zőgépről vagy a videokameráról is képes 
fogadni a kinyomtatandó képeket — 
amennyiben a képrögzítő eszköz erre 
alkalmas. Az 1550-es modell utódaként 





megjelent 1560 nemcsak kényelmes, 
számítógép nélküli használatot nyújt, 

de a sebessége is kiváló: fekete-fehér 
oldalból 22, színesből pedig 15 darabot 
nyomtat ki egy perc alatt, míg legna- 
gyobb felbontása 4800 x 1200 dpi. 

A PictBridge megoldást támogató 
készülékek képesek a korábbi Bubble Jet 
Direct megoldás szerinti eszközökkel is 
együttműködni. A PictBridge-t támogató 
fényképezőgépek és nyomtatók egyetlen 
USB-kábellel összekapcsolhatók, majd a 
segítségükkel margó nélkül nyomtatha- 
tók ki a megszokott méretű fényképek. 
Az 1560 nyomtató az Exif Print megol- 
dást is támogatja, amely a fényképező- 
gép által rögzített kiegészítő adatok 
segítségével a fényképek élethűbb repro- 
dukcióját teszi lehetővé. Az 1560 ajánlott 
végfelhasználói ára 129 dollár lesz. 

2 http:/www.canon.com 
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Itt van az egeremben 
Az IOGEAR Memory 
Mouse néven bemu- 
tatta az első olyan 
kisméretű, sokat 
utazó felhasz- 
nálóknak szánt 
egeret, amely 32 MB flashmemóriát is 
tartalmaz. Ha valaki a jövőben nem 
szeretne hordozható gépet hurcolni 
magával, és például USB-s flash- 
meghajtóra sem futja neki, akkor 

-— mi sem egyszerűbb - saját egerének 
bendőjében hurcolhatja magával bemu- 
tatóját, dokumentumait, vagy éppen 
kedvenc fényképeit, zeneszámait. A Me- 
mory Mouse 800 dpi-s felbontással dol- 
gozik, így nagy pontosságot kívánó 
munkákhoz is használható, illetve szűk 
helyen a kisebb kézmozdulatok révén 
kényelmesebb egerészést tesz lehetővé. 
A géphez USB-felületen csatlakozik, 
kábele behúzható, így szállítása is egy- 
szerűbb, mint a hagyományos, a hor- 
dozható gép táskájában általában kel- 
lemetlen gubancolódást okozó veze- 
tékkel ellátott példányoké. Az apróság 
ára 49 dollár. 

2 http:/www.iogear.com 





A papír a lényeg 

Az IBM és a SuSE közös bejelentése 
szerint a Linux a két cég munkájának 
eredményeképpen megkapta első 
biztonsági minősítését. A SuSE Linux 
Enterprise Server 8 egy IBM eServer 
xSeries gépen futva a Common 
Criteria feltételrendszere szerinti 
EAI.2-es minősítést nyerte el. A munka 
tovább folytatódik, a SuSE még az 
idén szeretné megszerezni az EAL3- 
szintű minősítést, illetve az Egyesült 
Államok védelmi minisztériumának 
kereskedelmi termékekre vonatkozó 
Common Operating Environment 
tanúsítványát, így igazolva, hogy ope- 
rációs rendszere a szolgáltatásokra és 
a biztonságra vonatkozó kívánalmak- 
nak egyaránt megfelel. A Common 
Criteria elismerés elnyerése fontos 
üzenet a szigorú követelményeket tá- 
masztó kormányzati szervek vagy vál- 
lalatok számára, illetve a Linux fejlő- 
désének szempontjából is lényeges 
előrelépést jelent, hiszen az év végére 
- ha minden jól alakul -— ilyen módon 
minősítésekkel teleaggatott SuSE-ter- 
jesztés egészen új, eddig haladásel- 
lenes módon kiváró piacokat nyithat 
meg a SuSE, és így az egész linuxos 
tábor előtt. 

2 http:/www.ibm.com/linux 

2 http:/www.suse.com 
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CD-író és kártyaolvasó egyben 

Az [/DMagic bejelentette az első olyan 
belső CD-újraíró meghajtót, amely egy- 
ben hétféle memóriakártya kezelésére 
képes kártyaolvasóként is használható. 





A meghajtó 52x sebességgel képes a 
CD-k írására, újraírást 32x sebességgel 
végez, és ha az alaplap egyik USB-csat- 
lakozóját hajlandóak vagyunk felál- 
dozni, akkor az IBM Micro Drive meg- 
hajtók és a Compact Flash, Multimedia 
Card, Secure Digital, Memory Stick, 
Memory Stick PRO és Smart Media kár- 
tyák kezelését is helytakarékos módon 
oldhatjuk meg vele. A cég hasonló meg- 
hajtókat eddig is kínált, ám csak külső 
kivitelben. Az új egység szállítása szep- 
temberben kezdődik meg, bevezető ára 
mindössze 79 dollár lesz. 

2 http:/www.iomagic.com 


Ok ellopják, mi fizetjük 

A Kensington új biztonsági termékeket 
mutatott be, ezek egyike a MicroSaver 
Guaranteed Notebook Replacement, 
amely valójában már nemcsak egy ter- 
mék, hanem 
egyfajta szol- 
gáltatás is. 

A gyártó vál- 
lalja, hogyha 
valakinek el- 
lopják a hor- 
dozható szá- 
mítógépét, holott az a Kensington fent 
nevezett termékével volt lezárva, akkor 
a vásárlástól számított egy éven belül 
történő lopásnál esetenként legfeljebb 
1500 dollár, személyenként évi 10 000 
dollár erejéig kártérítést fizet a károsult- 





nak, legalább részben pótolva a gép árát. 


Az új MicroSaver kevlár borítást kapott, 
belsejében rozsdamentes acélsodrony 
található, a cég állítása szerint a huzal 
40 százalékkal erősebb, mint a korábbi 
példányok. Esetében is érvényes a Ken- 
sington által nyújtott élettartam-garan- 
cia. A termék ára 55 dollár. A visszatérí- 
tés igénybe vételéhez a vásárlás tényét 
a vásárlástól számított 30 napon belül 
be kell jegyeztetni a gyártónál. 

2 http:/www.microsaver.com 
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Linuxos cégek támogatási szövetsége 
A ISANeten - Technical Support Alli- 
ance Network - az iparág legnagyobb 
gyártóktól független támogatási szö- 
vetségén belül új közösség jött létre: 

a Linux operációs rendszerrel foglal- 
kozók társulása. Az alapító tagok: a 
BEA, a Dell, az EMC, a HP a Network 
Appliance, a Novell, a SuSE, a Unisys, 
a Veritas és a VMware, de hamarosan 
további jelentkezőkre is számítani 
lehet. A közösség törekvése az, hogy 
akkor is hatékony támogatást tudjon 
nyújtani a vásárlóknak, ha azok több 
gyártótól származó elemekből — ame- 
lyek alatt eszközöket, operációs rend- 
szert és alkalmazásokat egyaránt lehet 
érteni — összeállított rendszert üzemel- 
tetnek. A cél nem kifejezetten az, 
hogy a vállalatok megosszák a tudá- 
sukat egymással, hanem az, hogy 
elkerüljék az ügyfél ,egymásnak való 
lepasszolását", aki rossz esetben a 
különféle cégek között őrlődve sehon- 
nan nem kap érdemi segítséget. 

A gyorsabbá és pontosabbá váló támo- 
gatás révén a Linux alapú rendszerek 
a komoly elvárásokat támasztó válla- 
latokhoz, küldetéskritikus környeze- 
tekbe is eladhatóvá válnak. 

A linuxos közösség a negyedik szer- 
veződés, amely a TISANet keretein 
belül jön létre, a korábbi három támo- 
gatási társulás Microsoft Datacenter, 
Storage Networking Industry 
Association és Mission-Critical 
Customer néven állt össze. 

2 http:/www-.tsanet.org 


Érdemes megjegyezni: CRESERC 

A Hitachi, a Mitsubishi és az NIT 
közös munkájának eredményeként 
napvilágot látott a CRESERC nevű 
titkosítási megoldás, amely elliptikus 
görbékkel dolgozó algoritmuson ala- 
pulva valósít meg nyilvános kulcsú 
titkosítási rendszert. A CRESERC kidol- 
gozásakor — mint a hasonló megoldá- 
soknál általában - finom egyensúlyt 
kellett találni a biztonság és a haté- 
konyság között, de a kutatók a saját 
állításuk szerint sikerrel jártak. 

A CRESERC kisméretű kulcsokat hasz- 
nál, mégis magas fokú biztonságot 
garantál, így a nyilvános kulcsú megol- 
dások új, az RSA algoritmus leváltására 
is alkalmas nemzedékét képviselheti. 
Ebben fontos szerepe lehet annak, ha 

a különféle szervezetek szabványként 
is elfogadják, márpedig erre jó esély 
mutatkozik, hiszen az érintett cégeknek 
több terméke szintén kapott már ilyen 
kitüntető címet. 


Tungsten 12 

A Palm megújította csúcsmodelljét: a 
Tungsten I utódaként megjelentette a 
Tungsten 12 kézigépet. Az új Iungsten 
32 MB memóriát kapott, pontosan 
kétszer annyit, mint elődje, operációs 
rendszere a legújabb Palm OS, és kijel- 
zője is élesebb, szebb képet ad. A ko- 
rábbi változathoz ha- 
sonlóan a gép képes a 
Bluetooth-kapcsolatok 
kezelésére és hangrög- 
zítésre, rendelkezik 
elektronikus levele- 
zésre, böngészésre, 
SMS-küldésre használ- 
ható ügyfélprogram- 
mal, illetve MP3-fájlok 
vagy mozgóképek lejátszására alkalmas. 
A Iungsten 12 ára 399 dollár. Megjele- 
nésével egy időben - kellemes mellék- 
hatásként - a Palm csökkentette az 
m130 és az m515 készülékek árát. 

2 http://www.palm.com 





Tally és Genicom — egyesülés 
Ha valakinek kellemes emlékei kötőd- 
nek a lally névhez, vigyázó szemeit 
ezentúl a lallyGenicom névre vesse. 
Az új név rég-új céget takar, amely a 
s ; ; Genicom [LP 
u Tally Genicom . ésa Tally AG 
összeolvadá- 
sával jött létre. A lallyGenicom a maga 
200 millió dolláros éves bevételével az 
egyik legnagyobb lesz azok között a vál- 
lalatok között, amelyek kizárólag nyom- 
tatókkal, nyomtatási kellékekkel és a 
kapcsolódó szolgáltatásokkal foglalkoz- 
nak. A változásból a cég meglévő ügy- 
felei, vásárlói elvileg semmit nem fog- 
nak érezni, legalábbis az árak emelke- 
désétől vagy a szolgáltatási feltételek 
megváltozásától nem kell tartaniuk. 
2 http:/www.tallygenicom.com 


DVD-lejátszó a Lindows.com-tól 

A Lindows.com jóvoltából megjelent 

az első kereskedelmi DVD-lejátszó prog- 
ram Linux alá. 

A Lindows.com 
jogtiszta módon tett 
szert a DVD-k tar- 
talmának dekódolásához szükséges kód- 
részletekre, így a lejátszó nem meglepő 
módon fizetős: 40 dollárba kerül; igaz, 

a hasonló célt szolgáló alkalmazások árát 
tekintve ez kedvezőnek is nevezhető. 

A program nemcsak a DVD-kkel, de az 
AVI, MOV, WMV és MP3 formátumok- 
kal is elboldogul. Többek között a 
Lindows.com oldalán vásárolható meg. 
2 http:/www.lindows.com/dvd 





Ouake-csata útközben 

A jövő év a mobil grafika lendületes 
térnyerését fogja hozni vélik az iparág 
szereplői. A Khronos Group, amely 

a mobil eszközökre szánt OpenGL 
Embedded Systems szabványt állítja 
össze, elkészült az előírás gyűjtemény 
1.0-s változatával. Eközben a Microsoft 
sem tétlenkedik, hamarosan napvilágot 
lát Direct3D Mobile APTI-ja, illetve a 
területen fontos szerepet betöltő Palm 
is saját rendszert készít, amely — szeren- 
csére — fő vonalaiban az OpenGL ES 
szemléletét követi. 

A kialakuló versengéshez hasonló küz- 
delmet láthattunk néhány éve a PC-s 
grafikai API-k között, ennek nyertese 

— legalábbis a játékprogramokat te- 
kintve — a Microsoft erejének köszönhe- 
tően a DirectX lett. A mobil eszközök 
piacán egyelőre jóval több befolyásos 
szereplő — mobiltelefon- és kéziszámí- 
tógép-gyártó — mozog, mint az asztali 
számítógépekén, így a verseny kime- 
netelét egyelőre kár megjósolgatni. 

A nagyteljesítményű mobilmegjelenítés 
nemcsak a programok, de az eszközök 
oldaláról is nagy kihívást jelent. A vezér- 
lőlapkáknak az akkumulátoros üzem- 
mód miatt csak nagyon kevés energiát 
szabad fogyasztaniuk, ugyanakkor bo- 
nyolult átalakítások, lebegőpontos szá- 


mítások elvégzését kell lehetővé tenniük. 


A nagyobb lapkagyártók, mint az Ali 
Technologies, az Intel, a Motorola vagy a 
lexas Instruments már az új piacra fenik 
a fogukat, nem különben az nVidia, 
amely hetvenmillió dollárért vásárolta 
meg a MediaO nevű, világcégek beszál- 
lítójaként pontosan a mobil grafikai 
eszközök piacára fejlesztő vállalkozást. 
Az állások elfoglalása hamarosan befe- 
jeződik, a háború nem sokára indul. 
Nekünk csak annyit dolgunk lesz, hogy 
a lehető leggyakrabban cseréljük le a 
mobiltelefonunkat. 


Felpörgetve 

A Hitachi a világon elsőként kínál 
7200-as fordulaton működő 2,5"-os 
merevlemezt. Az IBM-es időkből ismert 
Iravelstar sorozat E/7K60 jelzésű tagját 
a gyártó elsősorban kisméretű, állványra 
szerelt kiszolgálókba ajánlja, mivel az 
asztali meghajtókét megközelítő telje- 
sítményének és kis hőtermelésének 
előnyei ilyen környezetben mutatkoz- 
nak meg leginkább. Az új Iravelstar 

60 GB kapacitású, belsejében két darab 
üveg alapú korong pörög, az adatok 
írását-olvasását négy darab fej végzi, 
súlya 115 gramm. 

2 http:/www.hgst.com 
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A vonalkód visszavág 

Japánban megjelentek az első olyan mo- 
bilteleftonok, amelyek képesek a vonal- 
kódok olvasására. Mire jó egy ilyen 
készülék? A Java alapú alkalmazásoknak 
nak köszönhetően - a kéziszámítógé- 
pekhez hasonlóan — hamarosan üzleti 
alkalmazásokban is használhatók lesz- 
nek, ám egyelőre sokkal köznapibb célt 
szolgálnak. Ha valaki rendelni szeretne 
egy katalógusból, azt a távol-keleti or- 
szágban már mobiltelefonon is megte- 
heti, a vonalkódolvasó a cikkszámok 
hosszas bepötyögésétől kíméli meg a 
kedves vásárlót. Miután az érdeklődő 

a katalógusból kikereste a kívánt árut, 
egyszerűen az alatta található vonal- 
kódra irányítja mobiltelefonja figyelmét, 
amely beolvassa a megfelelő számsort, 
és már el is lehet küldeni a rendelést 

a megfelelő számra. 

A jelenleg még fennálló műszaki aka- 
dályok elhárítása után a telefonok arra is 
alkalmasak lesznek, hogy vonalkódokról 
például webcímet, telefonszámot olvas- 
sanak be nagy sebességgel, amelyet a 
felhasználó így egyetlen mozdulattal 
meglátogathat vagy felhívhat. A kétdi- 
menziós kódok beolvasása sem lehetet- 
len, ezekkel viszonylag nagy adatmeny- 
nyiséget is kényelmesen lehet majd 
bevinni a telefonokba. 


Viszlát, Ximian! 

A Novell - nem nyilvános feltételek 
mellett — felvásárolta az eddig magán- 
kézben lévő Ximiant. A Linux alá a 
vállalatok számára is fontos alkalma- 
zásokat fejlesztő Ximian megszerzése 
révén a NetWare visszaszorulása 

miatt kicsit szerepvesztetten ténfergő, 
egyre inkább a tanácsadás és a szol- 
gáltatások felé forduló Novell átfogóbb 
csoportmunka-megoldásokat kínálhat 
ügyfeleinek. 

A Ximian alapítói, Miguel de Icaza és 
Nat Friedman a továbbiakban a Novell 
csapatában folytatja munkáját. A Gnome 
és a Mono projekt mögött külön alapít- 
vány, nagy cégek és önkéntes fejlesztők 
százai állnak, így ezek sorsát a felvásár- 
lás ténye remélhetőleg nem befolyásolja 
hátrányosan. 


Medgyesi Zoltán 
(mzerettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 
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Egyes fejlesztők 


— például Alan Cox — 


azt állítják, hogy a 
szolgáltatásbővítés 
befagyasztása 


tulajdonképpen már 
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nincs érvényben. 


Linuxvilág 





Rendszermag-fejlesztési hírek 


A 2.5-ös fában megváltozott a megszakításkérés-kezelők visszaté- 
rési értéke, hogy jobban tudjanak kezelni bizonyos, külső eszközök- 
kel kapcsolatos hibákat. Ennek az lett az egyik következménye, hogy 
sok-sok vezérlőprogram használhatatlanná vált, és ki kellett javítani 
a forráskódjukat. A hivatalos rendszermagforrás részét képező ve- 
zérlőprogramok szemszögéből ez a változás visszatérő, nemkívá- 
natos napi teendőnek tekinthető, ami azonban véghezvihető. Ezzel 
szemben számtalan külső vezérlőprogram csak akkor lesz kijavítva, 
amikor valaki észreveszi, hogy már nem működnek, sőt a jogdíjas 
vezérlőprogramok esetében még inkább elhúzódhat a javítás. 
Bartlomiej Zolnierkiewicz az IDE-karbantartás hivatalos felelőse. 
Andre Hedfrick — legalábbis pillanatnyilag — félreállt, hogy a soros 
ATA- (SATA) illesztéssel és a gyártók lapkakészleteivel kapcso- 
latos kérdésekre összpontosítson. Továbbra is Alan Cox a hivata- 
los összekötő kapocs Linusszal az összes IDE-javítókészlet tekin- 
tetében. Andre úgy döntött, hogy visszamenőlegesen az összes 
olyan munkáját kiadja, amellyel hozzájárult a rendszermag 
fejlesztéséhez, mégpedig kettős felhasználási engedéllyel, nem 
csak a GNU általános közreadási feltételek szerint. A másik ilyen 
Lawrence E. Rosen nyílt szoftverfelhasználási engedélye. 
Benjamin Herrenschmidt átvette a Radeon Framebuffer kódot, 
amikor Ani Joshi, a kód hivatalos karbantartója abbahagyta a 
javítókészletek alkalmazását, és az üzenetekre sem volt hajlandó 
válaszolni. Ani eltűnése után Benjamin összegyűjtötte a fellelhető 
különböző javítókészleteket, és kiadta az új RadeonFB-frissítést. 
2003. május elején még mindig sok tennivaló akadt a vezérlőprog- 
rammal, és Benjamin úgy tervezi, hogy a 2.4-es fa jelenlegi alap- 
kódjával folytatja a munkát, és a szolgáltatásbővítés lezárása 
ellenére megpróbálja bejuttatni a program teljesen átírt változatát 
a 2.5-ös fába. Egyes fejlesztők — például Alan Cox — azt állítják, 
hogy a szolgáltatásbővítés befagyasztása tulajdonképpen már 
nincs érvényben. Ha ez tényleg így van, akkor a 2.6-os (vagy 
3.0-s) változat előkészítése jegyében elrendelt, a 2.5-ös változat 
állandósítására tett első kísérlet meghiúsult. 

Az I/0-vezérlőfüggvények (ioct1s) letűnőben vannak, amióta 

a SysFS a 2.5-ös rendszermag tervezési megbeszélései során 
megjelent. Azelőtt sokan kirohantak az ellen, hogy a vezérlőprog- 
ramok ioct1s függvényeket alkalmazzanak. Nem pusztán renge- 
teg volt belőlük, de egyszerűen nem is lehetett tudni, hogy ponto- 
san hány ilyen függvény létezik, és így megfelelő leírást sem lehe- 
tett hozzájuk készíteni. Habár még mindig számos olyan akad, 
amitől meg kell szabadulni, egyre több jelenik meg az ésszerűbb 
SysFS felületen. Továbbá az általános tisztogatás jegyében eltávo- 
lítják azokat, amelyeket soha senki nem használt, például a 

SCSI TOCTL SYNCésaSCSI TOCTI, BENCHMARK COMMAND 
függvényt. Úgy tűnik, hamarosan a SysFS lesz az elsődleges 
illesztési felület a felhasználók és a rendszermag között, felváltva 
az ioct1s-t és az engedetlen ProcFS fájlrendszert. 

Greg Kroah-Hartman már 2003 eleje óta a devés (és a /dev) 
lecserélésén munkálkodott, április közepén végül kiadta az udev 
első változatát, ami Dan Stekloff tervei és ötletei alapján készült. 
A /dev könyvtár mindig is rém rendetlen volt, százával hemzsegtek 
benne a szükségtelen fájlok. 


Zack Brown 
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1. 





A 2002 végén eladott kiszolgálói 
operációs rendszerek ennyi százaléka 
volt Linux: 15—20 


. 2006-ra vagy 2007-re az eladott új ki- 


szolgálói operációs rendszerek ekkora 
százaléka lesz Lintel (Linux on Intel): 45 


. Az informatika területén dolgozók 


alapfizetésének növekedési aránya 
jelenleg: 596 





. Ennyi SCO Unix-kiszolgálót váltanak 
fel Linux-kiszolgálóval az új-zélandi 
Farmlands mezőgazdasági kiskeres- 
kedelmi üzletlánc kirendeltségeinél: 28 
. Ennyi gazdálkodót szolgál ki a 
Farmlands: 15 000 


. Ennyi Linux-kiszolgálót adtak el 


Ázsia csendes-óceáni térségében 
2002-ben: 18 000 


. A fenti kiszolgálók eladásából szár- 


mazó bevétel dollárban: 58 millió 


. Várhatóan ennyi Linux-kiszolgálót 


adnak majd el Ázsia csendes-óceáni 
térségében 2007-ben: 47 000 


. A fenti kiszolgálók eladásából szár- 


mazó bevétel dollárban: 146 millió 


. Legkevesebb ennyi számítástechnikai 


csomóponton fut majd Linux az IBM 
új Blue Gene rendszerében: 65 000 


. Ennyi CPU van egyetlen Blue Gene 


lapkán: 32 


. Ennyi 32-bites CPU lapka van egyet- 


len Blue Gene-csomópontban: 64 


. Ennyi csomópont fér egy Blue Gene- 


keretbe: 3 


. Ennyi keret szükséges ahhoz, hogy 


elérjék az 1 PFLOP teljesítményt 

(1 petaflop — egymilliószor egymil- 
liárd matematikai műveletet másod- 
percenként): 64 


. Nagyságrendileg ennyi millió dollárt 


különítettek el a Blue Gene fejlesz- 
tésére a 2000-ben tett bejelentés 
szerint: 100 


Források 

1—3.: Meta Group, Inc. 
4—5.: New Zealand Herald 
6—9.: Gartner Group 
10—-15.: CNet 
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e KELLET 


Honi internet-saga 


A Sulinet Expressz (SEx) Program alapvető 
célkitűzése, hogy a pedagógusokat és a tanulókat 
otthoni használatra számítógéphez segítse. 


Az adókedvezményre jogosultak körét és a kedvezmény 
mértékét egészen pontosan a 2002. XLII., az adókról, járu- 
lékokról és egyéb költségvetési befizetésekről szóló tör- 
vények módosításáról szóló törvény írja le, amely szerint: 
11. 8 (3) A pedagógus, az oktató, a hallgató, a felnőtt- 
képzésben résztvevő magánszemély, valamint az a 
magánszemély, akinek gyermeke nappali rendszerű 
iskolai oktatásban vagy a felsőoktatásról szóló tör- 
vényben felsorolt felsőoktatási intézményben hitelesí- 
tett iskolai rendszerű első alapképzésben vesz részt, 
az összevont adóalap adóját csökkentheti az adóévben 
általa számítógép, számítástechnikai eszköz megszer- 
zésére (vásárlására, bérletére, lízingelésére) fordított 
összeggel, ha a megszerzés a Foglalkoztatáspolitikai 
és Munkaügyi Minisztérium, az Informatikai és Hírköz- 
lési Minisztérium vagy az Oktatási Minisztérium által 
kiírt pályázat keretében történik. Az adókedvezmény 
alapját és összegét a vételárat, a bérleti díjat, illetve a 
lizingdíjat tartalmazó, a magánszemély nevére kiállított 
számla bizonyítja. 
(4) A magánszemély által e § alapján igénybe vehető 
adókedvezményfek) összege adóévenként nem halad- 
hatja meg a hatvanezer forintot." 
Ha valaki számítástechnikai eszközt lízingel vagy bérel, 
és a lízingdíjat vagy bérleti díjat több adóév során szám- 
lázzák, akkor a kedvezmény a jogszabály érvényessége 
alatt minden egyes adóévben igénybe vehető, feltéve, 
hogy a többi feltétel is teljesül. Sajnos azonban a több- 
éves áruhitel nem tartozik ebbe a körbe, mivel ebben 
az esetben a termék vételárát a vásárlás időpontjában 
számlázzák, vagyis csak egyszeri hatvanezer forint adó- 
kedvezmény vehető igénybe. Egyetlen magánszemély 
több címen is lehet jogosult (például pedagógus és 
szülő), viszont a kedvezmény együttes összege ekkor 
sem haladhatja meg a bűvös hatvanezer forintos határt. 
Amennyiben szülőként kívánjuk igénybe venni az adó- 
kedvezményt, akkor egy gyermek után mindkét szülő 
igénybe veheti a legnagyobb kedvezményt, mivel nálunk 
jelenleg nincs családi adózás, csupán személyi jövede- 
lemadó. A kedvezmények azonban nem vonhatók össze 
egyetlen termék megvásárlására, mivel ugyanazt a 
terméket nem lehet kétfelé számlázni. Ehelyett mindkét 
szülőnek külön-külön kell megvásárolnia egy-egy számí- 
tástechnikai eszközt. 
A kedvezmény nem a vásárláskor érvényesíthető, 
ugyanis akkor természetesen ki kell fizetni a termék vé- 
telárát, hanem az adóév végén, az adóbevallás elkészí- 
tésekor jelentkezik: a vásárlónak a kedvezmény összegé- 
vel csökkentett, azaz hatvanezer forinttal kevesebb adót 
kell befizetnie. Arra azonban nagyon oda kell figyelni, 
hogyha az egyébként megfizetendő adó a kedvezmény 
összegénél kevesebb, akkor a különbség elvész, vissza- 
téríteni nem lehet. 
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Ki lehet igényjogosult? 

Az igényjogosultságot nem a vásárlásnál, hanem csak 
az esetleges adóellenőrzésnél kell igazolni, viszont az 
igényjogosultságnak a vásárlás időpontjában meg kell 
lennie. A többéves kedvezmény igénybevételénél (pél- 
dául lízing) a kedvezmény ideje alatt a jogosultságnak 
végig fenn kell állnia. Ha például a gyermek közben befe- 
jezi az iskolát, onnantól kezdve már nem jár a kedvez- 
mény. Mindettől függetlenül a forgalmazó például rész- 
letfizetés vagy lízing esetén saját elbírálás alapján kér- 
heti a jogosultságok igazolását szolgáló dokumentumok 
bemutatását. Ez a szülők esetében az iskolalátogatási 
bizonyítvány, a pedagógusoknál, oktatóknál pedig a köz- 
alkalmazotti jogviszonynak, illetve a munkaviszonynak 
az adott időpontban való fennállását igazoló okirat. 


Hol mit mennyiért? 

Eladói oldalról a törvényalkotó a részvételt pályázathoz 
kötötte, így azon cégek, konzorciumok termékei kerül- 
hetnek a SEx-en belül értékesítésre, akik erre pályáztak 
és nyertek. A programban megközelítőleg hetven cég 
vesz részt, a jogosultak az ország számos pontján vá- 
laszthatnak a több mint 250 féle számítógép, hetvenféle 
program — közöttük természetesen Linux-változatok is, 
például SuSE Linux —, valamint nyomtatók, kivetítők, 
digitális kamerák és modemek közül. 

Az eddigiek során e területen történt a legtöbb baklövés, 
sokáig sűrű homály fedte a mit-honnan-mennyiért kér- 
déskört. A pályázatnyertesekkel megkötött keretszerző- 
dés alapján az Oktatási Minisztérium minden értékesítő- 
hely számára SEx-emblémával ellátott, A4-es méretű 
Sulinet Expressz értékesítőhely tanúsítványt adott ki. 

A tanúsítványokat az eladótérben ki kell kifüggeszteni, 
megkönnyítve ezzel a vásárlók számára a döntést, hogy 
kérdéseikkel, panaszaikkal közvetlenül hova forduljanak. 
A termékekre öntapadós SEx-matricát és a termék és 
az értékesítőhálózat azonosítására alkalmas hologramos 
termékjelölő címkét kell ragasztani. 


Néhány szó a kisördögről... 

Nyilván sokakban megmozdult a kisördög, ám a pályázat 
megalkotói a magyar szokásokhoz híven azonnal igye- 
keztek néhány kiskaput bezárni: a SEx keretében az 
adókedvezmény igénybevételével vásárolt számítógépet, 
eszközöket a kedvezményt igénybevevő magánszemé- 
lyek a vásárlás évének utolsó napját követő harmadik év 
december 31-ig nem értékesíthetik, nem adhatják bérbe, 
vagy másnak térítésért vagy anélkül nem engedhetik át, 
gazdasági társaságba apport jogcímen nem vihetik be. 


2 http://ado.sulinet.hu/ 


Nagy Anna (Nagy.Annaolinuxvilag.hu) 
Linuxvilág felelős szerkesztője, akit 

a sors túltengő pedagógiai hajlammal 
és birkatürelemmel áldott meg. 

Két kiskorú gyermekével életre szóló 
programot írt magának. 





2003. szeptember 11 


0 Kiskapu Kft. Minden Jog fenntartva 
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d I-ÉTLT TRE ÉT 


A Linux-felhasználók Magyarországi Egyesületének 
(LME) életében rendkívül mozgalmasan telt az 
elmúlt pár hónap. 


2003. június 21—22. között Persányi Miklós környezetvé- 
delmi miniszter fővédnökségével került megrendezésre 

a negyedik Ózon fesztivál Budapesten, a városligeti 
szánkódomb mellett. 





A fesztivál célja az volt, hogy megpróbálják össze- 
gyűjteni és bemutatni azokat a válaszokat és megol- 
dásokat, amelyeket a civil társadalom ad a létét 
fenyegető környezeti, gazdasági, szociális és emberi 
válságokra. 

A fesztivál keretén belül beszélgetések, előadások, film- 
vetítések kaptak helyet, civil szervezetek mutatkozhattak 
be, és tapasztalatcserére, környezetbarát cégek és 
módszerek bemutatkozására nyílt lehetőség. 

Ezenkívül volt biopiac, és az otthon elkészíthető ételek 
garmadával (például a házi kefirrel, joghurttal, kenyérrel) 
ismerkedhettünk meg, a kovászkészítés és a csíráztatás 
rejtelmei is feltárultak, de életmód-tanácsadáson is részt 
vehettek az érdeklődők. Bepillantást nyerhettünk a kör- 
nyezetvédelmi jogérvényesítés útvesztőibe, és a függet- 
len médiák bevonásával (Indymedia), valamint a zöld és 
kritikai folyóiratokkal (Liget, Ezredvég, Eszmélet, Ökotáj, 
Kovász, Fedél Nélkül, Gaia), illetve egyéb kisebb újsá- 
gok, fanzinok, kézírásos újságok bemutatkozásával 
tapasztalatcserére is sor került. 

A ,Lehet más a világ!" mottójú eseményen egyesüle- 
tünk is képviseltette magát: a CD-író projekt számtalan 
linuxos CD-vel ajándékozta meg az érdeklődőket, illetve 
Hazai Géza, az LME elnökhelyettese Varga Csaba 
Sándor-ral, az FSF.hu alapítvány kuratóriumának elnö- 
kével tájékoztató jellegű előadást tartott. 


Linux-tábor 2003 

Czakó Krisztián (Slapic) jóvoltából harmadik alkalommal 
került megrendezésre az immáron hagyományosnak 
mondható Linux-tábor. 

A megközelítőleg nyolcvan látogató két turnusban 


(június 29—július 5., illetve július 6—12.) vendégeskedett 
Szerencsen, a , Csider-villában", azaz a Csider Andor 
által igazgatott Szerencsi Középiskolai Kollégiumban. 

A szállás 2—4 ágyas szobákban, a folyosók végén inter- 
neteléréssel, számítógéptermekkel, a nappalikban tele- 
vízióval, az alapértelmezett háromszori étkezés lebonyolí- 
tására étteremmel várta a tudásra szomjazókat, valamint 
a Linux iránt kevésbé érdeklődő családtagokat. A napi 
4—6 órás oktatás a kollégiumtól 500 méterre lévő gim- 
názium géptermeiben az alábbi témakörökben zajlott: 


1. hét 
e . Kezdők számára 
Altalános Linux-alapismeretek 


— Telepítés 

— Linux-rendszer felépítése, TCP/IP 

— Rendszermag 

— Grafikus felület (Gnome, KDE, ablakkezelők) 
— Hang 


— USB használata 

— Belső hálózatok 

— Hálózatbeállítás, névfeloldás 
— Samba 

— Levelezés 

— Nyomtatás (hálózati, cups) 
— Telepítés forráskódból 


e . Haladók számára 

— RAID 

— LVM 

— Programozás: C, PHP 

— Debian-csomagkezelés, -csomaggyártás 

— Biztonság: elmélet, RSBAC, Netfilter, 
átlátszó proxy, Zorp, VPN 

— Kiszolgálók: Apache, Bind, dhcp, 
PostgreSOL, cups, Sguid, LDAP 

— Lemez nélküli (Diskless) rendszerek 

— Levelezés: Postfix, Omail, Courier, Sguirrelmail 

— Vírus- és levélszemétszűrés 

— Grafikus rendszer távfelügyelete 


2. hét 
e . Kezdők számára 
— Linux teljesen kezdőknek 
— Debian-telepítés, -beállítás 
— Fájlrendszerek 
— Kiszolgálók: DNS, DHCP proxy, Samba, cups 
— Levélkiszolgálók 
— Apache, PHP 
— Hálózatbiztonság, csomagszűrés 
— Grafikus rendszer, hang 


e . Haladók számára 
— Lilo, grub 
— Programfejlesztés 
— Netfilter 
— Policy routing, 00S 
— Kiszolgálók: DHCP DNS, LDAP (azonosítás), 
Apache, Samba, Sguid 


Hi a 


— Levélkiszolgálók: Postfix, Omail, Vpopmall, 
Courier (POP3, IMAP) 

— Grafikus felület 

— Dial-in 

— Távfelügyelet 


e — Profik számára 
— Programfejlesztés 
— Debian-csomaggyártás 
— Biztonság elméleti szinten 
— RSBAC 
— Sandbox/jail-készítés 
— Csomagszűrés 
— VPN 
— Applikációs tűzfalak 
— Lemez nélküli rendszerek 


Kezdőknek a jelentkezéshez a Linux ismerete nem volt 
követelmény. Az ismeretanyagok átadását az alábbi 
oktatók végezték, akiknek ezúton is köszönjük az 
önzetlen segítséget: 


— Balázs Tibor (Cövek) 

— Kis Tamás (Dozer) 

— Szalai Ferenc (Szferi) 

— Czakó Krisztián (Slapic) 

— Tomka Gergely (Tomka) 

— Pásztor György (Pasztor) 

— Magosányi Árpád (Mag) 

— Gerendás Zoltán (ZGerendas) 
— Haluska György (George) 


I. Hackertalálkozó 

Elmondanám, de nem lehet..." — ez lehetett volna 

a találkozó mottója, ugyanis a magyar törvények már 
azt is büntetik, aki a meglévő hibákat pusztán 
nyilvánosságra hozza. 

2003. július 5—6. között került megrendezésre hazánk 
első ,betyár" találkozója Tatabányán, a KPVDSZ 
Művelődési Házban. Megszokhattuk, hogy az ilyen 

és ehhez hasonló országos érdeklődésre számot 

tartó rendezvények rendszerint fővárosunkban kerülnek 
megrendezésre. Kovács Krisztián, a rendezvény fő 
szervezője ennek ellenére lakhelyét, azon belül is az 
Újváros szívében található, 1976-ban épült KPVDSZ, 
azaz a kereskedelem, a vendéglátás, a pénzintézet 
dolgozóinak szakszervezeti művelődési házát válasz- 
totta. Az egykori KISKER Kultúrotthon jogutódja a helyi 
közösségi ház és , befogadó ház" szerepét is ellátja, 
és ezt saját erőből teszi, tehát nem önkormányzati 
ház, talán ezért is adott örömmel otthont a hazánkban 
még szokatlan rendezvénynek. 

A rendezvényt hozzávetőlegesen nyolcvan látogató 
tekintette meg. Mivel a látogatók teljes névtelenséget 
élveztek, csak tippelni lehet, hogy honnan érkeztek 

— de a beszélgetésekből, hozzászólásokból arra lehet 
következtetni, hogy a többség rendszergazda, illetve 
informatikai, biztonságtechnikai szakemberekből állt. 
Előadásokat a következők tartottak: 
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— Agócs Péter (Virusbuster Kft.) 
— Dr. Szentiványi Gábor (ULX Kft.) 
— Tesch Zoltán (Kancellar.hu) 

— Bodoky Tamás (index.hu) 

— Witch (a , szakértő") 


A meglehetősen foghíjasra sikeredett programból 
érdemes kiemelni /esch Zoltán és Bodoky Tamás 
előadását, valamint a vasárnap délelőtti elmélyült 
beszélgetést, ahol mindenki mindenkivel eszmét 
cserélhetett az előtérben. 

Gyakorlott konferenciaszervezők biztosan egynaposra 
tervezték volna a rendezvényt, gondoskodtak volna 
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étkezési lehetőségről, de azt nézve, hogy ez lényegében 
egyetlen ember (Kovács Krisztián) munkájának az 
eredménye, csak gratulálni lehet. 

A rendezvény alkalmából készített honlap egész évben 
folyamatosan várja az érdeklődőket a 

2 http://www.hacktivity.hu/ címen. Az eseményen 
készült videofelvételek az 5 ftp.eplanet.hu kiszolgálóról 
a ftp-hacktivity felhasználói névvel tölthetők le. 
Az eseményt egyesületünk apróbb ajándékokkal 
támogatta. 


Sziget fesztivál 

2003. július 30. és augusztus 6. között rendezték meg 
hazánkban a Hajógyári-szigeten Közép-Európa legna- 
gyobb fesztiválját. A Linux-felhasználók Magyarországi 
Egyesülete az FSF.hu Alapítvánnyal karöltve a , Lehet 
más a világ" összefogás által létrehozott Zöld Udvar 
vendégeként első ízben rendezte meg a , Szabad 
Szoftver Sziget Fesztivált", amelynek keretében a Sziget 
vendégeinek nyílt forrású programokat, operációs rend- 
szereket mutattak be, ezeket a látogatók természetesen 
ki is próbálhatták, előadásokat hallgathattak, valamint az 
LME CD-író projektjétől és a támogatóktól kapott Szabad 
Szoftver CD-khez juthattak. 

A rendezvény támogatóinak jóvoltából az érdeklődők 
SuSE és UHU-Linux terjesztésekkel találkozhattak, ezeket 
gyári CD-ken is megtalálható bővítményekkel vehették 
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kézbe. A szabad programokkal már jó barátságban lévők 
a Debiannal és egyéb Linux-változatokkal ismerkedhet- 
tek, ezeket a Szigeten a Multimédia Kft. által támogatott 
CD-író projekt segítségével haza is vihették. Támoga- 
tóink közül ki kell még emelnünk a Magyar BSD Egyesü- 
letet, az FSN-t, a Linux Support Centert és a Mission 
Critical Linuxot, valamint a Software Station céget. 
Vasárnap Varga Csaba Sándor, az FSF.hu alapítvány 
kuratóriumának elnöke és Szervác Attila, az LME és 

a Szabadon kampány jelenlévő képviselője tartott 
előadást. Az előadás anyagát médiapartnerünk, az 
Indymedia rögzítette. 

A jelenlévők éppúgy tájékoztatást kaptak a szabadon 
felhasználható programok társadalmi vonatkozásairól, 
mint a gazdaságiakról, valamint azokról az előnyökről, 
amelyek miatt a közigazgatási intézmények, az iskolák, 
a civil szervezetek, a magyar vállalatok és a magánsze- 
mélyek is egyre inkább a nyílt forráskódú megoldások 
felé fordulnak. 

A látogatók megtapasztalhatták, hogy milyen könnyű egy 
szabad operációs rendszert és a hozzájuk tartozó rengeteg 
kiváló programot kezelni. A bemutatókat a civil együtt- 
működés jegyében a Semmelweis Orvostudományi 
Egyetem vezetőképzője támogatta az általuk kölcsönadott 
233 MHz-es gépekkel, amelyek megmutatták a szabad 
programok erejét és kimagasló üzembiztonságát. 


Debian X Party 

A Linux-felhasználók Magyarországi Egyesületének 
Debian csoportja 2003. augusztus 15—17-én a Budapesti 
Műszaki Egyetem Schönherz Zoltán Kollégiumában, az 
Új Vár Klubban határozta el, hogy a Debian GNU/Linux 
10. születésnapja (augusztus 16.) tiszteletére megren- 
dezi a Szabad Szoftver Közösségi találkozóját, amit 
Debian X Party névre kereszteltek. 

A Debian projekt minden idők legnagyobb nyílt fej- 
lesztési modellre épülő szabad programja, amely- 

nek , az univerzális operációs rendszer" megterem- 
tése a célja. 

Mára a világ legnagyobb programrendszerévé nőtte ki 
magát, mert gyors, biztonságos és bármilyen felhasz- 
nálói igény kielégítésére alkalmas felületet nyújt az 
otthoni felhasználóknak, cégeknek, irodai alkalmazot- 
taknak és fejlesztőknek egyaránt. 

A résztvevők az ünneplés mellett hasznos munkával 
kívánják tölteni a hétvégét. Erre jó lehetőséget ad a 
DDTP rendszer (Debian Description Translation Project), 
amelynek segítségével könnyen fordíthatók azok a rövid, 
három-négymondatos leírások, amelyek magyarul 
segítik elő a Debian alapjának telepítését, a beállításokat 
és a felhasználó igényei szerinti programok telepítését. 
Magyarországon akadt már egy példátlanul sikeres 


akció, amikor az FSF.hu Alapítvány aktivistái által szerve- 


zett OpenOffice.org-fordítás alkalmával bebizonyították, 
hogy egy jól megszervezett akcióval milyen óriási 
eredményeket lehet elérni. Az LME Debian csoportja 
hasonló eredményességre törekszik. 


V. GNU/Linux szakmai Konferencia 

A Linux-felhasználók Magyarországi Egyesülete 2003. 
november 8-án (szombaton) rendezi meg az V. GNU/Linux 
szakmai Konferenciát, seregnyi neves előadó és kiállító 
részvételével a Hotel Novotel Budapest Centrumban 
(Budapest, VIII. Rákóczi út 43—45.; 

2 http://www.novotel-bud-centrum.hu/indexhu.html]). 

A tanácskozás területén kiállítás és vásár is lesz, ahol 
linuxos szakkönyveket, programokat és egyebeket lehet 
majd megvásárolni. A konferencia fő témája a honosítás 
és a magyar fejlesztések. 

A konferenciával kapcsolatban felmerülő véleményeket, 
kérdéseket a Konferencia 2003 (konf(olists.linux.hu) 
listára várjuk. A program reggel 10 órakor kezdődik 

és 18 óráig tart. Idén a támogatóknak köszönhetően 

a belépőjegyek ára az alábbiak szerint alakul: 


e . Támogatott belépő 
A támogatott belépő térítésmentes. A támogatott 
belépővel érkező vendégek a konferenciakiadványon 
és 1-2 apróságon kívül semmilyen egyéb szolgáltatás- 
ban nem részesülnek. Előzetes regisztráció kötelező! 


e — Üzleti belépő 
Az üzleti belépőjegy ára 19 900 -- 259 áfa, azaz 
bruttó 24 875 forint. 
Üzleti belépőt vásárló vendégeink a következő 
szolgáltatásokban részesülnek: 

— konferenciakiadvány, 

— reklámanyagok, 

— jegyzettömb, reklámtoll, 

— konferencialogós, galléros póló, 

— az előadások bemutatóinak kinyomtatott 
egybefűzött példánya, 

— névre szóló kitűző, 

— büfé (kávé, üdítő, sütemény), 

— üzleti ebéd a hotel éttermében, 

— a konferencia zárásakor a szervezők nagy 
értékű ajándékot sorsolnak ki az üzleti belépő- 
tulajdonosok között. 

Az előzetes regisztráció szintén kötelező! 


e — VIP-belépő 
A VIP-belépő térítésmentes, közvetlenül nem 
igényelhető. Ilyen belépőket az LME díszvendégei 
kapnak, valamint a támogatók is hozzájuthatnak, 
és ezeket munkatársaik vagy az általuk meghívott 
személyek szabadon felhasználhatják. 
A VIP-belépővel érkezők ugyanazokat a 
szolgáltatásokat élvezhetik, mint az üzleti 
belépőjegyet vásárló vendégeink. 


Gibízer Tibor (gibzorolinuxportal.hu) 
Újságíró, immár nyolc éve a Linux 
elkötelezett híve. Imádja a kutyákat, 

a kerékpározást és az autós csavargást. 
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A Linux Journal honlapján 
számtalan gond megoldá- 
sához találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakori 
kérdéseket és az egyéb 
útmutatásokat a 

2 www. linuxjournal.com 
honlapon olvashatjátok el. 
A rovatban közzétett 
válaszokat Linux-szakértők 
kis csapata készítette el. 
További kérdéseiteket 
szívesen fogadják 

(angol nyelven) a 

2 www.linuxjournal.com/ 
[/-issues/techsup.htmi 
címen, ahol csak egy 
kérdőívet kell kitöltenetek, 
de a bts(ossc.com címre 
levelet is írhattok. A levél 
tárgyában szerepeljen 

a ,BIS" kulcsszó. 
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A hónap szakmai tanácsai 


Kapcsolat időtúllépése 

A telnet és az SSH-kapcsolatok időtúllépés miatt 
megszakadnak. A tcsh parancsértelmezőt használom, 
és a pty-eszköz, amire bejelentkezem, fel van sorolva a 
/etc/securetty állományban. Ez nem az autologout 
hibája. Ha letiltom az autologout-ot, akkor is meg- 
szakad a kapcsolat, nagyjából egy óra múlva. Amikor ez 
történik, a felhasználó még mindig bejelentkezettként 
van felsorolva és a parancsértelmező működik. A folya- 
matazonosítóját kilőve lehet csak befejezni a futását. 
Floyd Miller, floydostudiodust.org 


Nagyon valószínű, hogy a tűzfalban van a hiba. Gyakran 
megesik címfordító és álcázó tűzfalaknál, hogyha egy 
összeköttetésen egy bizonyos ideig nincs forgalom, ak- 
kor az útválasztó eldobja a kapcsolatot, mert feltételezi, 
hogy helytelenül lett lezárva. Ennek az az oka, hogy bizo- 
nyos ügyfelek nem küldenek megfelelő lezárási kérést, 
és nem lenne okos dolog fenntartani ezeket a halott kap- 
csolatokat, mert rendszermag-erőforrásokat kötnek le. 
Chad Robinson, crobinsonarfgonline.com 


Valószínűleg címfordító átjárón mész át, ami a tétlen 
TCP-kapcsolatokat egy óra tétlenség után megszakítja. 
Rendszergazdaként add ki a következő parancsot: 
ecao 600 5 /oroc/sya/met / ajová / 

tcp keepalive time 

Ezután, ha SSH-t használsz, küldj életben tartó TCP-cso- 
magokat, hogy a kapcsolat ne haljon el: 

sem -o "KesoAlivezyes cÉlgÉ 

Marc Merlin, marc bts2google.com 


Kevesebbet kell gépelned, ha beírod a 
ProtocolkKkeepAlives 300 

sort a —/.ssh/config állományba, hogy az SSH minden 
kapcsolatra ötpercenként életben tartó csomagot küldjön. 
Don Marti, dmartKossc.com 


Támogatás az Intel Videóhoz? 
Videokártyám egy beépített Intel 82845G6/GL, ami nem 
hajlandó együttműködni a Linuxszal (Red Hat 8.0). 

A Linux a telepítés során lekérdezi, de nem indul el 

a grafikus mód, és a startx végzetes hibát ad. 
Jafar Borhan, jafar borhancoyahoo.com 


A Google-n keresve találtam egy oldalt, ahol leírják 

a rendszer beállítását ehhez a videokártyához: 

2 http://www.linuxcare.com/labs/certs/ibm/netvista- 
m42/rh80-config.epl. Frissítsd a felsorolt csomagokat, 
majd futtasd az Xconfigurator programot. 

Marc Merlin, marc bts2google.com 


Régi rendszermagok kiselejtezése 

A Red Hat Network segítségével frissítem a program- 
jaimat. Engedélyeztem az uo2date programnak, hogy 
a rendszermagot is frissítse. Viszont a /boot lemezterület 
kezd megtelni. Hogyan távolíthatok el néhányat a régi 
rendszermagok közül? Nem hinném, hogy öt különböző 
rendszermagra lenne szükségem a /boot lemezrészen. 
Bob Wooden, bobwoodenC2netwalk.com 


Egyszerűen távolítsd el a nem kívánt rendszermagokat. 
Az rpm -aga I grep kernel parancs megadja, hogy 
mely rendszermagcsomagok vannak telepítve, és az 
rom -e paranccsal a régiek eltávolíthatók. Azt javas- 
lom, hogy legalább kettőt tarts meg, így ha valami 
rosszra fordul a jelenlegivel, marad egy tartalék. 

Mario Bittencourt, mneto(2dargo.com.br 


Ez nemcsak rendben van, de ez a helyes rendszergazdai 
magatartás. Csak a hasznos rendszermagokat tartsd 
meg - általában kettő szükséges: az elsődleges rend- 
szermag és a biztonsági tartalék, ha valami történne az 
elsődlegessel. Annyi különféle változatot, mint neked 
van, ritkán kell megtartani, hacsak nem különlegesek az 
igényeid, például rendszermag-illesztőprogramokat 
fejlesztesz és próbálsz ki. 

Chad Robinson, crobinsonarfgonline.com 


USB flashmeghajtó? 

Hogyan fűzhetek be egy USB flashmeghajtót? A /proc/ 
bus/usb/devices/ könyvtárban megjelenik a meghajtó. 
A hardverkereső nda4-ként azonosítja fat 32 fájlrend- 
szerrel, de nem tudom befűzni, sem a fájlokat elérni. 
Callum Benepe, callumboyahoo.com 


Úgy tűnik, hogy nincs betöltve nálad az usb-storage 
modul, ami viszont szükséges ehhez az eszközhöz. 
Olvasd el a Linux USB Guide dokumentumot a 

2 http://www.linux-usb.org honlapon. Itt részletesen 
leírják a megfelelő illesztőprogramok betöltésének és 

az eszköz befűzésének a módját. 

Greg Kroah-Hartman, gregokroah.com 


A Windows eltüntette a LILO menüjét 
Számítógépemre Red Hat 7.1 van telepítve, és egy 
másik lemezrészen Windowst használok. Nemrég újra- 
telepítettem a Windowst. A rendszerindítás után a gép 
többé nem kérdezi meg, hogy Windowst vagy Linuxot 
akarok-e futtatni, hanem egyből a Windowst indítja. 
Helyreállítható-e a Linux? 

Kunal S Doddanavar, kunal s d(9indiatimes.com 


A Windows vagy eltávolította, vagy letiltotta a Linux 
rendszerbetöltőjét, ami a Red Hat 7.1 esetén a LILO. 
Indítsd a rendszert a helyreállítólemezről, fűzd be a Linux 
lemezrészét például így: mount /dev/hda1 /mnt, és 
futtasd a run 1lilo -R /mnt parancsot a rendszerin- 
dítás előtt. Ha GRUB-ot használtál, a grub-insta11 
oldja meg a gondot. 

Marc Merlin, marc bts2google.com 


Az újabb Red Hat-terjesztéseknél — amelyek a GRUB 
rendszerbetöltőt használják — indítsd el a rendszert a 
helyreállítólemezről, és telepítsd újra a GRUB-ot a 
grub-instal1 paranccsal. Ha nem készítettél hely- 
reállítólemezt, akkor a rendszert a telepítő CD-ről indítsd, 
helyreállító módban. 

Christopher Wingert, cwingerteogualcomm.com 
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SmartFLeX SFT-CXC 
Network Terminal 

Az SFT-CXC karakteres és grafikus 
terminál a SmartFLeX Technologies 
beágyazott Flash 
Linux-rendszerén 
alapul. Az SFT-CXC 
karakteres terminál- 
üzemmódja akár öt 
egyidejű munkame- 
net is támogat 

— teljes képernyős 
üzemmódban, 
etherneten vagy soros kapcsolaton 
keresztül. X-terminálként használva 
egy XDMCP-munkamenetet használ- 
hatunk a hálózati gazdagéphez. A kü- 
lönféle ablakkezelők használatára 
felkészítő bővítményeket mellékelték 
a programhoz. Az SFT-CXC egy 
webböngésző program segítségével 
a távolból is beállítható. 

Adatok: SmartFLeX Technology, Inc., 
623 Selvaggio Drive, Surte 220, 
Nazareth, Pennsylvania 18064, 
telefon: 610-/46-2390, 

2 http:/Awww.smartflextech.com 


ATG 6 

Az ATG 6 a Red Hat Advanced 
Server 2.1-re telepíthető e-kereske- 
delmi, üzleti folyamatokat és kap- 
csolatokat kezelő alkalmazáscsomag. 
A program önkiszolgáló rendelésfel- 
vételre, számlakezelésre és vevőol- 
dali feladatok (például termék-össze- 
hasonlítás, ajándékküldés és fizetés) 
végrehajtására képes. A projektek 
logikai munkafolyamatát önműködő 
eszközök irányítják, a kölcsönhatá- 
sok teljes sorozata önműködően 
megy végbe. Az egymáshoz kapcso- 
lódó modulok kezelik a közzététellel, 
kereséssel, elemzéssel, fizetéssel 

és a csalások elleni védekezéssel 
kapcsolatos feladatokat. Az ATG 6 
többféle meglévő vállalatirányítási 
és vevőkapcsolati rendszerrel össze- 
kapcsolható. 

Adatok: ATG, 25 First Street, 
Second Floor, Cambridge, 
Massachusetts 02141, 

telefon: 61 7-386-1000, 

2 http:/Awww.atg.com 





Trustix Small Office 
Server 

A Trustix megjelentette a Írustix 
Small Office Servert, amelyet leg- 


www.linuxvilag.hu 


feljebb 25 hálózatba kötött felhasz- 
nálót kiszolgáló környezetbe tervez- 
tek (frissíthető az ötven felhasználós 
változatra). A Small Office Server 
tartalmazza a Írustix terjesztést, és 
web-, levél-, proxy- és helyi hálózati 
kiszolgálóként használható. Telepít- 
hető a meglévő gépekre, vagy előre 
telepített formában megtalálható az 
IBM xSerles gépein. A terjesztésnek 
része a RAV vírus- és levélszemétirtó 
programja, valamint a NetVault biz- 
tonsági mentéseket készítő alkal- 
mazása. A Small Office Server támo- 
gatja a felhasználók állományainak 
központosított tárolását, a hálózati 
gyorsítótárazást és a központosított 
beléptetést. 

Adatok: Trustix, 4819 Emperor 
Boulevard, 4th Floor, Durham, 

North Carolina 27703, 

telefon: 919-313-4599, 

2 http:/Awwwitrustix.com 


Interphase 
IPSec-gyorsítókártyák 

Az Interphase új hálózatbiztonsági 
termékvonalának első képviselői 

a 45 NS (PMC) és az 55 NS (PCI) 
hálózatbiztonsági gyorsítókártyák. 

A kártyák alkalmazásával megszün- 
tethető a VPN-ek, átjárók, útválasz- 
tók és tűzfalak szűk keresztmetszete, 
mert a kártyák a számításigényes 
IPSec-feldolgozást a számítógép pro- 
cesszora helyett elvégzik. A gyorsító- 
kártyák képesek a fejlécelemzésre, 

a hasznos forgalom kiemelésére, 
tömörítésre, titkosításra, hitelesí- 
tésre és csomagok összeállítására. 
Mindkét kártya 500 Mb/Ss sebességű 
3DES-átvitelre képes, és gyorsítja 

a DES, MD5, SHA-1, RC4 és AES 
biztonsági algoritmusokat. További 
jellemzők: 66 MHz-es PCI-sín, 64 MB 
saját memória, teljesen kétirányú 
0C3-sebességek támogatása és 

512 K egyidejű munkamenet. 
Adatok: Interphase, Parkway Centre, 
Phase 1, 2901 North Dallas Parkway, 
Sulte 200, Plano, lexas 75093, 
telefon: 800-32/7-8638, 

2 http://www.interphase.com 


SnapGear Embedded Linux 
Új, ingyenes beágyazott Linux-ter- 
jesztést adott közre a SnapGear Inc. 
A SnapGear Embedded támogatja az 
MMU nélküli processzorokat (például 





ColdFire, ARM és SPARC), valamint 
az MMU-val rendelkezőket, többek 
között a SuperH-t, az Xscale-t és 

a x86-ot is. A terjesztés a SnapGear 
által karbantartott uClinux-foltokon 
alapul, segédprogramokat, szab- 
ványos API-kat és programkönyv- 
tárakat tartalmaz az egyedülálló 
programokhoz, valamint forráskód- 
gyűjteményt. A SnapGear Embedded 
ingyen letölthető a webhelyéről, 

de megfelelő díj ellenében CD-leme- 
Zen is elérhető. 

Adatok: SnapGear, Inc., 

7984 South Welby Park Drive 101, 
West Jordan, Utah 84088, 

telefon: 801-282-3492, 

2 http://www.snapgear.com 
(company site), 

2 http://www.snapgear.org 
(downloads). 


3DBOXX M4 Opteron 
munkaállomások 

A BOXX Technologies bejelentette 
térbeli leképező munkaállomásainak 
új családját, amelyek két Opteron 
processzort tartalmaznak. A 240-es, 
242-es és 244-es processzorokkal 
felszerelt gépek már kaphatóak. 

Az M4-es munkaállomás nVidia 
Ouadro rendszert használ a térbeli 
tartalom leképezésére és mozga- 
tására a Maya, 3DS Max, Softimage 
XSI, LightWave 3D és Houdini prog- 
ramokkal. Az alapkiépítésű munka- 
állomás tartalmaz egy AMD-8111 
Hyperlransport PCI-alagutat, egy 
AMD-83151 Hyperlransport AGP-ala- 
gutat, 128 bites kétcsatornás me- 
móriasínt, legfeljebb 8 GB ECC-hiba- 
javítással ellátott 333 MHz-es DDR- 
memóriát, négy DIMM-bővítőhelyet, 
kétcsatornás UltrabMA 133 IDE- 
vezérlőt és hatcsatornás hangot. 

A munkaállomások egyéni felszerelt- 
séggel is megrendelhető. A jó hőel- 
vezetés érdekében a gépek könnyű 
alumíniumházban vannak, és két 

92 mm-es ventilátor fújja bennük 

a levegőt. 

Adatok: BOXX Technologies, Inc., 
10435 South Burnet Road, 

Sulte 120, Austin, Texas 7/8758, 
telefon: 877-877-2699, 

2 http:/Awww.boxxtech.com 
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Hogyan teszi a Linux okosabbá a vállalatokat? (2. rész) 


Hogyan Is változtatja meg a Linux a hagyományos vállalatok 


információtechnológiáját? 


ézzünk meg például egy leve- 
let, amelynek a szerzője névte- 
lenséget kért: , Egy Fortune 
50-be tartozó vállalatnál dolgozom, ahol 
az I[-részleg új nyílt forrású irányvo- 
nalat léptetett érvénybe. Emellett egy 
jóváhagyott nyílt forrású eszköztárat is 
kiadott (saját, belső , márkanév" alatt), 
amit az alkalmazottak egy weblapról 
tölthetnek le. Már a 3.0 változatnál tar- 
tunk, ami mind Unix, mind Windows 
alatt megtalálható. Az eszköztár Unix- 
oldalon GNU és egyéb eszközökből 
tevődik össze, Windows-oldalon pedig a 
Cygwin eszköztárat tartalmazza. 

A Linux (jelenleg a Red Hat) az egyike 
az ,eszközöknek". 

Az eszköztár-projektet vezető srác szin- 
tén a szabad programok szószólója. 

Az irányelv kinyilatkoztatott célja, hogy 
lehetőséget adjon a vállalatnak a megta- 
karításokra. Nyilvánvaló cél az is, hogy 
lehetőséget biztosítsanak a vállalatnak 
szellemi tulajdonuk megvédésére egy 
harmadik fél (ez a Microsoft) manipulá- 
ciójával szemben. 

Az irányelvnek része az úgynevezett 
,ne kérdezz, ne mondd el" elv. Az IT 
beleegyezett, hogy nem panaszkodik, 
ha valaki elhatározza, hogy ezeket az 
eszközöket bármelyik, a felhasználó 
által használt számítógépre telepíti. 

Az összes nem vezetői beosztásban 
dolgozó alkalmazottnak most engedélyt 
kell kérnie helyi vezetőjétől az eszköz 
letöltésére és telepítésére. A vezetőknek 
nincs szükségük ilyen engedélyre, hogy 
az eszközt a saját gépükre telepíthessék. 
Az irányelv szerint az II semmilyen 
módon sem szól bele a dologba. Így 

a linuxos eszközök és a többi szabad 
program terjedése természetesen és 
egységesen fog megtörténni. 

Mielőtt ezt az irányelvet létrehozták 
volna, még a GNU Emacs programnak 
is át kellett esnie a hivatalos II-felülvizs- 
gálati, illetve -engedélyezési eljáráson. 
Még akkor is, ha a főnököd akarta, az IT 
harcolhatott ellene, ha kedve volt. AZ új 
irányelvvel azonban mindez már csak 
történelem." 

A szervezetben az irányelv elkerülhetet- 
lenül alkalmazkodik a fejlesztési életcik- 
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lushoz. Ma ezek a trendek a Linuxnak 
kedveznek - nagy időket élünk. A Li- 
nux-fejlesztőkről szóló legújabb felmérés 
szerint (mely fejlesztők más felületeken 
is dolgoznak) az Evans Data Corp. gyors 
átrendeződést figyelt meg a kereskedel- 
mi Unixtól és Windowstól a Linux irá- 
nyába: , Az esetek negyven százalékában 
a Linux az elsődleges választás. A Win- 
dows 2000-nek nagyon erős, 29 száza- 
lékos részesedése van, amit a Windows 
XP követ 12 százalékkal. A helyzetkép 
azonban folyamatosan változik. A követ- 
kező évben a válaszadók száma, akik a 
Linuxot elsődleges fejlesztési felületként 
használják, 15 százalékkal nőni fog, 
vagyis negyvenről 55 százalékra." 


Forgalmazók: azt nyújtani a 
vásárlóknak, amit ők szeretnének 

A forgalmazók új kényszerítő ereje az, 
hogy azt adják a vevőiknek, amit ők 
szeretnének, és ne próbálják meg bele- 
kényszeríteni őket egy választás nélküli 
kapcsolatba. Köszönik, ebből már 
elegük van. Műrten Mickos, a MySOL 
(5 http:/mysgl.com) ügyvezetője hisz 
abban, hogy az olyan vállalatok, mint 
az övé is, képesek felébreszteni az I1- 
tudatosságot. Azt nyilatkozta, hogy a 
MYySOL azért tudja sikeresen árulni a 
szabad programot (a MySOL GPL 
felhasználási szerződésű), mert , több az 
érték a látható kódok fejlesztésében, 
mint abban a forráskódban, ami nem 
hozzáférhető; egy óriási vevő- és fej- 
lesztői közösség tagjai vagyunk, mind 
szenvedélyesen fejlesztjük az alapkódot. 
Minden nap bebizonyítjuk, hogy létez- 
het olyan kereskedelmi kapcsolat, ame- 
lyik szabad programot eredményez." 
Ez a kereskedelmi kapcsolat még mindig 
nem az, ami a legjobb forgalmazóknál 
ható. A nagy vevőknél mindez mindkét 
oldalon középszinten megy végbe. 

A MySOL vevői listája lenyűgöző, köz- 
tük van a Nokia, a Yahoo, a NASA, a 
Silicon Graphics és a Cisco. Jeremy 
Zawody, aki magát ,Yahoo-technikus- 
nak" nevezi, a Yahoo gazdasági osztá- 
lyán dolgozik. A következőket mondja: 
A MYySOL ahhoz hasonlóan fog beszi- 


várogni a vállalathoz, ahogyan a Micro- 
soft SOL Server tette, de annál sokkal 
nagyobb sebességgel. A MySOL olyan 
az Oracle-nek, mint a Linux a Windows- 
nak. Lassan, de határozottan felkúszik a 
táplálékláncon, ugyanúgy, mint a Linux 
tette." Amikor megkérdeztem Márten 
Mickost, hogy vajon a MySOL verseny- 
zik-e az Oracle-lel, azt válaszolta, hogy 
nem. , Inkább helyettesítjük az Oracle-t, 
mintsem versenyzünk vele." 

Wim Coekaerts (3 http:/otn.oracle.com/ 
oramag/Coekaerts.htm]), az Oracle 
linuxos magfejlesztő csoportjának veze- 
tője a következőket nyilatkozta: , A Linux 
nagyon, de nagyon fontos az Oracle szá- 
mára. Szinte már linuxos cég vagyunk." 
Büszkén állítja, hogy magfejlesztői 
csoportja hozzájárult ahhoz, hogy 
Linuxot , vállalati szintűvé" tegye. 


Történet az új szahványról 

Az Oracle-hez hasonlóan a többi 
forgalmazónak is alkalmazkodnia kell 
ahhoz a világhoz, amelyben a Linux 

és a nyílt forrás követői az alapvető 
II-hátteret alkotják. Ez a háttér gyorsan 
válik szabvánnyá, akárcsak a , százas" 
szeg és a csavarhúzó. A forgalmazók 
mindig üdvözölni fogják e háttér elő- 
nyeit, és hozzájárulnak a fejlődéséhez, 
de a kapcsolatuk formája az elvonttól 
el fog tolódni a kézzelfogható felé, az 
elvont játéktérről a valódi II-projektek 
felé, ahol valami hasznoshoz járulhat- 
nak hozzá. Amikor ez meg fog történni 
és a programipar felnő, az érdem végre 
oda fog kerülni, ahova már régóta 
kellett volna: az okos emberekhez, akik 
elkezdték használni a Linuxot, hogy 
vállalataikat okossá tegyék — függet- 
lenül attól, hogy ezek a vállalatok mivel 
kereskednek. 


indx douraat 2005" 4ÚNTÜszethieeszám 


Doc Searls (docAssc om) 
A Linux Journal szerkesztője 
és a Cluetrain Manifesto 
társszerzője. 





A kisegíitó lehetőségek szempontjából nézve 


Hogyan állja meg a helyét a Linux a fogyatékkal élő felhasználók támogatása terén? 





z angol accessibility kifejezés 
AA a fogyatékkal élőket és a csök- 

kent képességűeket támogató, 
az általuk is használható megoldásokra 
vonatkozik, ezeket magyarul talán a 
, kisegítő lehetőségek"-nek nevezhet- 
nénk. A kérdés most az, hogy mennyire 
használható a Linux a fogyatékkal élők 
és a csökkent képességűek számára? 
A válasz ma még nagymértékben attól 
függ, hogy milyen fogyatékról van szó. 
A kisegítő lehetőségekkel kapcsolatos 
kihívások megoldását célzó egyre egysé- 
gesebb törekvések mögött talán maga 
a linuxos szellemiség a legfontosabb 
hajtóerő. A nyílt forrású és szabad prog- 
ramok világának alapját olyan közösségi 
értékek alkotják, amelyek senki kizárását 
nem engedik meg. Mindenkinek joga 
van használni a programot, mindenki 
megnézheti és módosíthatja a kódot 
— miért maradna ki valaki csak azért, 
mert nem tud képernyőről szöveget 
olvasni, vagy nem tudja egy időben 
lenyomni az ALT és az FI gombot? 
A Linux tényleg példamutató eredmé- 
nyeket mutat föl a kisegítő lehetőségek 
terén. Löbbnyire azonban a kisegítő le- 
hetőségek támogatása sajnos csak esetle- 
ges — ez egyrészt annak a ténynek a 
mellékterméke, hogy a Linux gyökerei 
mélyen az ASCII[-kód világába ágyazód- 
nak, másrészt annak, hogy a Linux kima- 
gaslóan jól képes szinte bármilyen esz- 
közről bemenetet olvasni. Nem mintha a 
fejlesztők szándékosan hagynák ki a kise- 
gítő lehetőségek támogatását — egysze- 
rűen csak ezt a szempontot mindeddig 
nem alkalmazták a kódellenőrzés során. 
Egy másik hatóerő a szóban forgó prog- 
ramoknak elsőbbséget biztosító törvé- 
nyek és irányelvek megjelenése. Ezek 
közül a legjelentősebb az amerikai kor- 
mány beszerzési gyakorlatát szabályozó 
508. bekezdés néven ismert jogszabály. 
E nemrég szigorított rendelkezés szerint 
az amerikai kormány köteles kisegítő 
,elektronikus és informatikai megoldá- 
sokat" alkalmazni a munkahelyeken 
és a nyilvánosan elérhető elektronikus 
tájékoztatási rendszerekben, amennyi- 
ben ilyen technológia rendelkezésre áll. 
Az 508. cikkely hatására megnőtt az 
érdeklődés a kisegítő megoldások iránt, 
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egyszerűen azért, mert az amerikai 
kormány az egyik legjelentősebb vevő 
az informatikai piacon - jelenleg mint- 
egy negyvenmilliárd dollárt költ évente 
erre a célra, és ez a szám a várakozások 
szerint mindössze öt év alatt ötven szá- 
zalékkal nőhet. Hozzátéve ehhez azt a 
megbecsülést, amit a linuxos szakembe- 
rek a közösségi értékek iránt mutatnak, 
szorongató érzés arra gondolni, hogyha 
csak hajszál híján is, de a Linux esetleg 
mégsem felel meg a társadalmi elvárá- 
sok e mércéjének. 

Az utóbbi évek során számos fejlesztő 
dolgozott - elsősorban a Sun Microsys- 
tems, de az IBM, a Red Hat és a Ximian 
támogatásával is felvértezve — az új 
Gnome 2.0-s környezet kisegítő keret- 
szolgáltatásainak módszeres kidolgozá- 
sán. Őszintén szólva nehéz elképzelni, 
hogy ez az 508. cikkely nélkül is meg- 
történt volna-e, de ezeknek az erőfeszí- 
téseknek a haszna messze túlterjed az 
Egyesült Államok határain. A Gnome 
kisegítő szolgáltatásainak honlapja 

(2 http://developer.gnome.org/projects/ 
gap) jelenleg talán a legjobb forrás arról, 
hogy mit is jelent és hogyan valósítha- 
tók meg a kiegészítő lehetőségek a 
Linux esetében. 

Az egész kérdéskör ugyanakkor be- és 
kiviteli kérdésként is összegezhető. 

A gondok - bármilyen sokfélék és ösz- 
szetettek számtalan megjelenési formá- 
jukban - alapvetően egyszerűek. 
Bármilyen beviteli módról legyen is szó, 
amin keresztül egy számítógép adatokat 
fogadhat a felhasználóktól, akadnak 
olyanok, akik képtelenek használni őket. 
Ugyanígy minden emberi fogyasztásra 
szánt kiviteli módhoz találhatók olyan 
felhasználók, akik az adott közvetítő 
eszközön keresztül nem képesek befo- 
gadni a kimenetet. A kérdés, hogy 
miként lehet ezt az alapvetően bináris 
elven működő gépet rávenni arra, hogy 
igény szerint bármilyen eszközről beme- 
netet fogadjon, és miként alakítható a 
kimenet megjelenési módja úgy, hogy 

a lehető legszélesebb felhasználói kör 
számára értelmezhető legyen. 

Az erkölcsi kötelesség nyilvánvaló. 

A közösségi programok csak akkor 
lehetnek valóban közösek, ha mindenki 





számára elérhetők. Lehetséges, hogy ez 
az igény bizonyos területeken akadályt 
jelent majd. Többnyire azonban nagyon 
kevéssé zavaró, egész egyszerűen azért, 
mert a Linux foglalatokat (sockets) 
használ. A munka javát nyilvánvalóan 
erre szakosodott fejlesztők fogják elvé- 
gezni, mivel a jól működő megoldások 
elkészítéséhez sok különleges ismeret 
szükséges. De amit meg akarnak 
valósítani, az nem különbözik attól, 
amit mindannyian akarunk - és vissza 
is érkeztünk a közösségi szellemhez. 
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Janina Sajka 

Az Amerikai Alapítvány A Vakokért 
(American Foundation for the Blind, AFB) 
műszaki kutatási és fejlesztési Igazgatója. 
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A hihetetlen Hulk erejétől az ILIM Halálcsillagáig 


A július elejétől a magyar mozikban is bemutatott 
Hulk című film szintén az ILM linuxos leképezőtelepén készült. 


Linux Journalban (és a Linuxvilág 2002. augusztusi 
AA számának 32. oldalán) megjelent történet — amelynek 
témája az Industrial Light éz Magic (ILM) Linuxra 
való átállása volt asztali gépeiken és leképezőtelepükön 
-— rekordmennyiségű olvasói visszajelzést váltott ki. 
A Csillagok háborújának Halálcsillaga mégis létezik! Bár nem 
mint fenyegető, bolygókat megsemmisítő fegyver, hanem mint 
az a leképezőtelep, ami az Industrial Light gz Magic 
műhelyében készülő számos mozifilm hátterében húzódó 
számítási teljesítményt adja. 
,A Linux folytatja töretlen fejlődését" — állítja Cliff Plumer, 
az ILM műszaki igazgatója. , Leképezőtelepünk jelenleg több 
mint 1500 processzorral bír, és az asztali gépek révén minden 
este csaknem 1000 továbbival gyarapszik." A leképezőtelep mind 
a kizárólag erre a célra használt processzorokat, mind pedig az 
üresjáratban dolgozó asztali gépek teljesítményét. kiaknázza 





A Halálcsillag leképezőtelep 

,Leképezőtelepünk szinte teljes egészében linuxos gépekből 
áll, amióta csak SGI gépeinket lecseréltük" — tájékoztat Mike 
Thompson rendszertervező. , A telep körülbelül 750 csomó- 
pontból, azaz 1500 processzorból áll." A leképezőtelep 1U 
kétprocesszoros, keretszerelésű sorba kötött számítógépekből 
áll. Hagyományos értelemben véve ez nem egy szuperszámí- 
tógép — mindegyik félig függetlenül, hálórendszerbe kötve 
működik, nincs meg az egyetlen munkafolyamat futtatásának 
kötöttsége, mint egy szuperszámítógép esetén. Itt az ILM-nél 
egy saját, parancsfájl-ütemező program, az ObaO vezérli az 
egyes gépekre jutó munkát. 

Ahogy a rendszerek nyers teljesítménye növekszik, egyre 
nagyobb az ILM géptermének elektromosság- és hűtésigénye. 
, Fontos, hogy csökkentsük a fogyasztást és a hőmérsékletet 

— világít rá Ihompson. Mi AMD Athlon 1600-as processzorok 
mellett döntöttünk, olyan alacsony fogyasztású változat 
mellett, amit nem könnyű beszerezni." Mindegyik csomópont 
2 GB memóriával rendelkezik, ami 4 GB-ra bővíthető, és a cso- 
mópontok a két processzor kihasználása végett egyszerre két 
munkafolyamatot futtatnak, de ez néha egy folyamatra 
csökken, amikor a teljes memóriát ki szeretnénk aknázni. 

Az AMD-vel felszerelt csomópontok a RackSaver cég RS-1100-s 
egységei. A RackSaver a National Association of Broadcasters 
(NAB, azaz Műsorszóró Társaságok Nemzeti Egyesülete) kong- 
resszusán keltette fel az ILM figyelmét, és kapta meg azt a 
lehetőséget, hogy ajánlatot tegyen a leképezőtelep megépí- 
tésére. A RackSaver legnagyobb ellenfele a nehézsúlyú IBM 

és a Dell. A cég előnye David Diggers vezérigazgató szerint 
abban áll, hogy a versenytársakéhoz képest kétszeres sűrűségű 
kiszolgálókat képesek gyártani. , A piacnak ebben a szeletében 
az ILM, Pixar és Warner Brothers stúdiókkal kötött üzleteink 
révén nagyon erősek vagyunk" - büszkélkedik David. 

A RackSaver telep kiszolgálói 100BASE-IX csatolókon keresztül 
csatlakoznak egy Foundry 8000 hálózati kapcsolóhoz, amely 
ezeket a kapcsolatokat egy gigabites központi hálózati köte- 
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1. kép Az ILM RackSaver linuxos leképezőtelepe jelenleg 1500 
processzorral bír, és a Star Wars Episode III elkészítéséhez ez a szám 
a kétszeresére fog emelkedni 


Lf E. 


lékké összesíti. , Nemrégiben bővítettük ki a hálózati központot 
egy 10 gigabites összeköttetéssel, ami nagyon sokat segített 

— meséli Thompson. Egy fájlkiszolgáló-maggal és 2500 leké- 
pezőközponttal rendelkezünk, ez napi mintegy 70 IB össze- 
sített forgalmat jelent." 


Mitől rettenetes a zöld szín? 

A Hulk nem egy szokványos képregény-mozi" - világosít fel 
Doug Sutton műszaki igazgató. , Évek óta ez jelentette az egyik 
legnagyobb kihívást a munkáink közül. Egy 15 láb magas fickót 
élethűen megalkotni - ez igazi erőpróbát jelent." A Hulk egy 
számítógéppel előállított digitális színész, bonyolult 
érzelmekkel és zöld színű bőrrel. 

,A filmeket úgy gyártják, hogy az emberek ne nézzenek ki 
zöldnek, vagyis a zöld színt eltolják — magyarázza Rod Bogart, 
a vezető programmérnök. ,Mi Kodak Premiere nyomtató- 
készletet használunk, ennek mélyebbek a színei, mint a Kodak 
Visionnek. Ha a szereplő zöld, ahogy Hulk is, elég nehéz olyan 
látványt létrehozni, ahol a bőr színe tényleg zöldnek hat. 

A Jurassic Park zöld dinoszauruszai könnyebb feladatot jelen- 
tenek. A dinoszauruszoknak nincsenek olyasfajta fényfoltjaik 

a bőrükön, mint az embereknek." A nézők kevésbé megbocsá- 
tóak az emberi arccal kapcsolatban - főleg ha az még zöld is. 
,A zöld a fehérhez közelítve sárgás árnyalatot vesz fel — teszi 
hozzá Sutton. Muszáj egy megjelenítőn is ellenőrizni, mielőtt 
az ember elfogadná vagy elvetné". 

Az élő jeleneteket San Francisco utcáin rögzítették. Jennifer 
Conelly egy utca közepén áll, és egy nagy zöld fickónak játszik, 
aki nincs is ott. Egyetlen segédeszköze egy pózna, a tetején egy 
zöld fejjel. , Készítettek néhány igazán jó valós hatást, robbanást, 
de főleg számítógépes grafikáról van szó — magyarázza Sutton -, 


at Lp 


a Maya és a Softimage keverékéről ". 


A Cineon és az OpenEXR 

Egy film képeinek a rögzítése nagyobb dinamikatartományt 
igényel, mint amit a JPEG vagy a PNG támogat. A Kodak 
Cineon hosszú ideje a digitalizált film szabványos formátuma. 
A Cineon 10 bites logaritmikus formátum szemben a JPEG-gel, 
ami 8 bites lineáris (azaz 24 bites RGB), így a Cineon nagyobb 
dinamikával és — különösen a fekete közelében — gazdagabb 
színkészlettel rendelkezik. Ahogy növekedett a számítási telje- 
sítmény, és a legtöbb számítás a lebegőpontos ábrázolásra 
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2. kép Az ILM saját ObaO ütemezője éppen egy Linux-parancsfájllal 
vezérelt leképezést futtat a Hulk című film készítése során 
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20 terabájtos EMC fájlkiszolgálóval 


váltott át, a 10 bites logaritmikus formátumban való munka 
vált korlátozó tényezővé. Az OpenEXR egy új, lebegőpontos 
képformátum. 

, Az OpenEXR formátum egy film jobb digitális ábrázolását 
biztosítja, mivel több mint 30 f-egység dinamikatartománnyal 
rendelkezik, anélkül, hogy veszítene a pontosságából - fejti ki 
a véleményét Plumer. A korábbi 8 bites fájlftormátumok csak 
körülbelül 7-10 f-egységgel rendelkeztek, és különösen nagy 
kontrasztú képeket már nem voltak képesek megfelelő módon 
megjeleníteni." 

Az ILM 2000 nyarán alkotta meg az EXR formátumot, és olyan 
filmek elkészítése során használta, mint a Harry Potter és 

a bölcsek köve, a Men in Black II, a New York bandái, a Jelek 
(Signs5), az Álomcsapda, a Hulk, a Van Helsing, a Peter Pan, 

az Idővonal és a Karib-tenger kalózai. 

Az Open EXR veszteségmentes tömörítést használ, mint a 
PNG, nem pedig a JPEG-hez hasonló veszteséges tömörítést. 
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Valójában létezik egy kihasználatlan Piz12 veszteséges tömö- 
rítési lehetőség is. A PNG-vel és JPEG-gel ellentétben az 
OpenEXR hullámkódolást használ, ami lényegében egy olyan 
faszerkezet, ami a képpontok közti előjeles különbségeket 
tárolja. Mivel a számok nagyságrendje kisebb és kevesebb 
egyedi érték fordul elő, a Huffman-kódolás nagyobb haté- 
konysággal tudja összetömöríteni az adatokat. Az EXR támo- 
gatja a 32 bites lebegőpontos, a 32 bites egész és 16 bites lebe- 
gőpontos ábrázolást, tetszőleges számú csatorna esetén. 

Az egyes csatornák különböző színmélységgel rendelkez- 
hetnek, például az RGBAZ képek esetén nagyobb Z-mélységre 
van szükség - a jellemző érték a 16-16-16-16-32. A Z2-csatorna 
fizikai mélységet jelöl, nem pedig egy szín- vagy alfamaszkot, 
képzeljük el inkább úgy, mint valami szonárt. 2003 januárjában 
az ILM kibocsátotta a nyílt forrású OpenEXR-t. Az első olyan 
nyílt forrású program, ami támogatta ezt a formátumot, a 
CinePaint volt. 


A CinePaint 

A CinePaint, amit a közelmúltig FilmGimp néven emlegettek, 
egy képenként haladó mozgófilm-retusáló rendszer, ami 
1998-ban vált ki a Gimpbőól. Számomra is váratlan módon 
lettem a CinePaint-projekt vezetője, miután a Linux Journal 
számára írtam néhány cikket a FilmGimpről. A megszokott 
állókép-formátumokon túl a CinePaint támogatja a filmgyár- 
tásban elterjedten használt fájlformátumokat is. Ezek között 
található a Cineon, az RnH 16 bites lebegőpontos formátum 
(a Rhythm £ Hues által létrehozott formátum, ami a 32 bit 
felének a levágásával jött létre), a Radiance HDR, a LogLuv 
Titff és most már az Open EXR. A CinePaint OpenEXR bővít- 
ménye az ILM munkája. 


Az SDev, a LUT és a rácsvonalak 

,soha nem akarunk egy képet a megfelelő SDev nélkül 
megnézni" - jelenti ki Sutton. Nagyon fontos, hogy azt lássuk, 
amit a folyamat végén eredményként kapunk. Az SDev egy 
szimulációs eszköz, amivel a monitort a filmhez hasonlatossá 
tudjuk tenni. Az OpenEXR-re való áttérés óta nem használunk 
LU1I-okat többé, de SDev-eket igen." A LUT egy keresési tábla, 
amelyet egy kép gammájának a kijavításához használtunk 
korábban. A monitorok fényereje nem arányos a bemeneti 
feszültséggel, inkább a bemeneti feszültség valamelyik 
hatványával. Ezt a kitevőt nevezzük gammának, amelynek az 
értéke a kijelzőtől függ. A Macintosh gépek jellemző értéke 1,8, 
ami a PC-k esetén 2,2 körüli. 

,A LUT-ok működésének elve leginkább a kontraszt változ- 
tatására épül — magyarázza Bogart. A LUT ellenben nem képes 
a színtelítettség növelésére vagy csökkentésére." A LUT helyett 
az ILM-nél egy összetettebb rácsvonalas számítási módot 
alkalmaznak. A rácsot 13x13Xx13 méretű térbeli kockáknak 
kell elképzelnünk - tulajdonképpen háromdimenziós indexelt 
tömbről van szó. Egy páratlan számot használnak, a középpont 
szürke. A rácsvonalas ábrázolásban minden RGB érték leképe- 
zésre kerül, szemben a LUTI-tal, ami csatornánkénti leképezést 
végez. Három egymástól független keresési tábla alkalmazása 
nem megfelelő egy film látványának visszaadásához — külö- 
nösen telített zöld szín esetén nem. A rács egy 64 K bejegyzést 
tartalmazó számított tábla segítségével állítja be a 12 pontos 
filmgörbének megfelelő értéket. Egy 0 és 1 közé eső rácsindex 
háromvonalas vagy négyoldalú interpoláció alkalmazásával 

és az ezt követő gammakorrekciójával szolgáltatja a három 
értéket. A folyamat lassabb, mert minden egyes képpontot 

a többivel együtt kell kezelni, de élethűbb, mint az RGB- 
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csatornákon alapuló kikeresés. , A rácsos módszer nem csak 

a Hulk esetén alkalmazható eredményesen" — mutat rá Bogart. 
A Minority Report esetén egy színtelenítő folyamat látványát 
szimuláltuk a rácsmódszerrel. A LUT színtelítetlenség előidé- 
zésére sem alkalmas." 


GPU-programozás az nVidia Cg-vel 

A nyers 16 bites OpenEXR adatformátumot Halfnak (fél) is ne- 
vezik - utalva a 32 bites lebegőpontos ábrázolás megfelezésére. 
A Half adatformátum az nVidia grafikus kártyák belső adatfor- 
mátuma. Jó lenne, ha a rácsmódszer számításai, amik jelenleg 
a központi feldolgozó egységet terhelik, közvetlenül a video- 
kártya processzorán (GPU) futhatnának. Ennek megvalósítása 
a grafikus kártyák fejlődésével egyre közelebb kerül. , Már 
nagyon várjuk, hogy ez lehetővé váljon" — vallja be Bogart. 

A képpel kapcsolatos számításokat a GPU képpontárnyaló 
rendszerére szeretnénk átterhelni." Az nVidia egy új, C-szerű 
fordítót, illetve programkönyvtárat kínál, a Cg-t, képpontkó- 
dok - közkedvelt nevükön , árnyalók" (shaders) — futtatására a 
GPU-n. Az ATI hasonló technológiát kínál High Level Shading 
Language (magas szintű árnyaló nyelv) néven, a 3Dlabs pedig 
az OpenGL Shading Language fejlesztésén dolgozik. 

A GPU programozása hasonló a beágyazott rendszerek progra- 
mozásához, ahol a kódot a gazdafelületen fordítjuk, majd ezt 
töltjük le a beágyazott rendszerre. A GPU-programok futásidő- 
ben fordíthatók és tölthetők át a grafikus kártyára. A fordító- 
program (compiler) a futásidejű programkönyvtár részét képezi. 
Néhány 3D-programcsomag, például a Softimage és a Maya 
már kezdi használni a Cg-t a leképezési teljesítmény növelésére. 


Modellezés és leképezés 

Az Alias/Wavefront Mayát korábban a részek (particles) és 
néhány szereplőmozgási modell kidolgozására használták. 

A Pixar RenderMan és a Mental Ímages cég Mental Ray prog- 
ramja végezte a leképezést. A sugárkövető leképezők tükrö- 
ződő felületei jobbak, de az előállításuk hosszabb időt vesz 
igénybe. Hála a gyorsabb és olcsóbb Linux-rendszereknek, 

a módszer gyakorlati alkalmazása egyre egyszerűbbé válik. 
Mind a RenderMan, mind pedig a Mental Ray támogatja az 
árnyaló programozást a képek egyedibbé tételére. A Render- 
Man könnyen elsajátítható saját árnyaló nyelvvel rendelkezik. 
A Mental Ray a C nyelvet használja, ami több munkát igényel, 
de hatékonyabb. Hogy melyik programot használjuk, azt 
jelenetenként eldönthetjük, minden jelenet leképezése egy 
ütemező parancsfájl vezérlése szerint történik. 


Az Obaü ütemező parancsfájl 

,Florian Kines — aki az OpenEXR megalkotásának hátterében is 
áll — írta az ütemező parancsfájlunkat, sok más mellett, amit az 
SGI Írix óta alkotott — tudatja velünk Hess. Jó hasznát vettük a 
nagygépnek és az asztali számítógépeknek. Amikor elkezdtük 
a Linuxra való átállást, jobb erőforrás-gazdálkodást szerettünk 
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volna megvalósítani." Az ObaO első változata jelenetek szerint 
különválasztotta a gépeket — ez bizony nem túl hatékony 
erőforrás-kezelés. 

, AZ ObaO kiváltására indított IMP projektünk, ami egy köz- 
pontosított erőforrás-kezelő rendszert állított volna az ObaO 
helyére, nem járt sikerrel — mondja Hess. Visszatértünk az 
ObaO-hoz és ennek Linuxra való átültetéséhez, ami körülbelül 
két hétig tartott. Három vagy négy hónappal ezelőtt Florian 
úgy döntött, megoldja, hogy bármelyik jelenet bármelyik gépet 
használhassa." Az ObaO egyenrangú (peer to peer, P2P) üte- 
mező rendszer. Ennek az az előnye, hogy egy esetleges kiszol- 
gálóhiba esetén az egész rendszer nem kerül kapcsolat nélküli 
állapotba. Az ObaO2 a teljes ütemezés megvalósítására egyet- 
len gépet használ - a futtatására tanácsos egy független gépet 
használatba venni. Az ObaO2 kiszolgáló elvesztése nem jelenti 
az egész géppark leállását. Léteznek más ütemező rendszerek 
is, mint a népszerű zárt forráskódú termék, a Platform LSE 
vagy a nyílt forrású Condor és OpenPBS ütemezők, de az ILM 
az ObaO használatának a folytatását tervezi. 

Az SGI a folyamatok megfigyelhetősége céljából hozzáadott 
néhány képességet az Irix-rendszermagjához, ezáltal a pro- 
cesszoridő és az ideiglenes helyek követhetővé váltak. 

Ezektől az értékektől függ, hogy az ILM gépidejét hogyan 


adja vissza a központi elszámolás a projektek számára. Az 
ILM azt tapasztalta, hogy a Linux /proc fájlrendszer nem biz- 
tosítja maradéktalanul ezeket a statisztikákat, vagy az rend- 
kívül sok többletmunkával jár, és az ObaO-t sem támogatja 
változtatások nélkül. 


A Halálcsillag 

rendszermagjának módosítása 

, Florian arra kért, hogy foglalkozzam a Linux-rendszermag 
néhány kérdésével — meséli Hess. Az egyik dolog, hogy a Linux 
nem ad módot a futási szálak (thread) és a folyamatok (process) 
megkülönböztetésére. A ps minden szálat külön folyamatként 
tüntet fel." Néhány munkafolyamat, amilyen a Mental Ray is, 
keretenként több szálat is képes futtatni egymással párhuzamo- 
san. A Linux top vagy ps parancsa minden szálat úgy mutat, 
mintha 1 GB RAM-ot foglalna le, pedig az csak olyan osztott 
memória, ami többszörösen lett figyelembe véve. A Linux arról 
sem képes adatokat szolgáltatni, hogy melyik munkafolyamat 
nyit ideiglenes fájlokat. Az ObaO-nak szüksége van ezekre az 
ismeretekre ahhoz, hogy egy munkafolyamat félbeszakításakor 
ezeket az ideiglenes fájlokat is törölhesse. Hess egy linuxos 
magmodult hozott létre, hogy csapdát állítson a nyitott állomá- 
nyoknak, elágazásoknak, másolatoknak, kijáratoknak és átne- 
vezéseknek, abból a célból, hogy lehetővé váljon a pontos kimu- 
tatás elkészítése. A rendszermagmodul a munka nagy részét 
elvégzi, de a hurkolt (hooked) hívásoknak minden olyan mun- 
kafolyamatot figyelmen kívül kell hagyniuk, amit nem az 

ObaCO futtat. Ehhez a rendszermag módosítására van szükség. 
,A ptrace zászló (flag) egyik használaton kívüli bitjét használ- 
tam fel — magyarázza Hess. Minden x86 munkafolyamat rendel- 
kezik egy 32 bites ptrace-vektorral. A 2.4.20-astól kezdve 10 bit 
jelzi a ptrace módot, mint amilyen a lépésenkénti végrehajtás. 
Valamikor a múlt év folyamán a Linux vagy a glibc megváltoz- 
tatta a ptrace zászló működését, így az elágazásoknál törlődik. 
Azt tapasztaltam, hogy a rendszermag törli ezeket a biteket, és 
megtartja a 32. bitet." Hess elmondása szerint a 2.5 rendszer- 
magban az OPROFILE tulajdonság továbbfejlesztett elszámolási 
(accounting) képességekkel rendelkezik, így esetleg nincs 
szükség a módosítására. A ptace zászló (flag) használaton 
kívüli bitjének felhasználása gyors módja annak, hogy a mun- 
kafolyamatokat az ObaO-feladatokhoz tartozónak tüntessük fel. 
, Ez az egyik nagyszerű dolog a Linuxban - lelkendezik Hess. 
Mivel rendelkezünk a forráskóddal, saját magunk is kieszközöl- 
hetjük ezt a módosítást, ez pedig nagyon gyors megoldás. Nem 
kell a fejlesztőt egy ilyen egyedi műszaki megoldás fejlesztésébe 
bevonni, mint azt az Irix esetében meg kellett tennünk." 


Gondok az NFS-sel 


, Ekkora tűzerővel, amivel a leképezőtelepünk rendelkezik, 
bármelyik fájlkiszolgálót hanyatt lehetne dönteni" — vélekedik 
Ihompson. A nukleáris robbanások leképezése a Hulkban elég 
döcögős - ez a fő oka későbbi bánatunknak. Egy grafikusnak 
könnyű felprocesszoroznia a leképezést (vagyis több pro- 
cesszort hozzárendelnie a feladathoz) egészen addig a pontig, 
amikor is a fájlkiszolgáló végleg megadja magát. Hétszázszor 
annyi adatot kell elosztanunk, mint korábban." 

Az ILM Sun 13-as lemezegységtömböket használ az NFS 
kiszolgálására. A Linux NFS-ügyfélként való üzembe helyezése 
számos kérdést vetett fel, amikor másfél évvel ezelőtt működni 
kezdett. A Linux NFS UDP-csomaghibája miatt (a 2.4.18-as 
változattól javítva) a Sun Solaris kiszolgáló néhány órás 
működés után száz százalékra pörgött fel, és használhatatlanná 
vált. A Sun saját Solaris rendszermagmoduljával és IP-verem- 
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foltjával sietett a segítségünkre a Linux-hiba behatárolásában. 
A Linux NFS UDP választásának másik gyötrő kérdése a for- 
galomvezérlés hiánya. , Amikor túlterhelési gondok kezdenek 
jelentkezni a fájlkiszolgálónkon, a leképezőtelep szolgálatmeg- 
tagadási támadást indít a fájlkiszolgálón — kesereg Thompson. 
Ismét megpróbáljuk a TCP NFS-t egy Linux-ügyfélgépen, 
most, másfél évvel később. Jövő héten indul a kipróbálása." 

A ICP körülbelül öt százalékos többletterhelést jelent. 

Az ILM mostani 20 TB-os tárolókapacitását a jövő évben a 
kétszeresére emeli. , A Csillagok háborúja III. epizódjára leké- 
pezőtelepünket duplájára növeljük — dicsekszik Ihompson. 
Ezt a RackSavertől rendelt 3000 új csomóponttal könnyen 
megtehetjük, de tönkretehetné a fájlkiszolgálónkat." Ihomp- 
son azt tervezi, hogy az NFS-kiszolgáló összeomlását egy 
fürtözött fájlkiszolgálóval fogja megakadályozni - egy Sistina 
GFS-sel vagy valami hasonlóval; a fájlkiszolgálás így nem 
korlátozódik kizárólag az ILM berendezéseire. 
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Napi digitális munkaanyagok (dailies) 

Az ILM a világ minden tájára küldi napi munkaanyagait az 
ILM Conduiton (ILM-csatorna) keresztül, ami egy titkosított 
SSL-protokollt használó, szabadalmazott fájlküldő rendszer. 

A Blowfish segítségével mindent kétszeresen rejtjeleznek. 

Az ILM lejátszói futtathatók Windowson, Macintoshon és 
létezik egy webalapú Java kisalkalmazás-változat is, ami 
mindenütt futtatható. , Az MJPEG-A Ouicklime a fő mozgó- 
filmtároló formátumunk — mondja Thompson -—, de a Conduit 
bárminek az átvitelére alkalmas, így illesztési adatok (match- 
move data), digitális képek, napi munkaanyagok is továbbít- 
hatók. A felhasználók a napi munkaanyagokat szabályos háló- 
zati kapcsolataikon keresztül, linuxos gépeiken játszhatják 
vissza. Ez valóban lenyűgöző, ehhez korábban SGI beren- 
dezésre volt szükség." A napi munkaanyagok számára az ILM 
20 IB tárterülettel rendelkezik EMC Clarrion FC4700-as töm- 
bökben, amelyek előterében négyprocesszoros Sun 420R 
kiszolgálók állnak 4 GB memóriával és gigabites hálózati 
csatlakozással. 


Zöld jelzés a Linuxtól 

,A Linux használata számunkra annyit jelent, hogy bármilyen 
feladat megoldásához hihetetlen mennyiségű számítási tel- 
jesítmény áll a rendelkezésünkre - jelenti ki Sutton. A Hulk- 
ban a haj és bőr megjelenítésére már nem is tudom, hány 
mintázatréteget használtunk. Félelmetesen összetett jelenetek 
megalkotására vagyunk képesek a Linux használatával." 

A stúdiók tevékenysége a rendelkezésre álló pénz és idő 
függvénye - a gyorsabb és olcsóbb Linux több film elkészíté- 
sét teszi lehetővé. 
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Users Journalban, a Data Based Advisorban jelentek 
meg, és számos tanácskozás anyagában megtalálhatók. 
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Kilenc SSH-trukk 





Titkosítsuk minden kapcsolatunkat SSH segítségével! 


z SSH az rsh és az r1login távoli bejelentkezésre 
AA használható, de nem titkosított programok utódja. 

Az rsh és az rlogin, akárcsak a telnet, régi szár- 
mazással büszkélkedhet, mostanra azonban túlhaladottá és 
biztonsági szempontból elégtelenné vált. Ugyanakkor e prog- 
ramok meglepően nagyszámú, igen hasznos szolgáltatást 
gyűjtöttek össze a Unix-fejlesztések két évtizede alatt, így a 
legjobbak közülük az SSH-ba is bekerültek. Következzék az 
a 9 trükk, amit a leghasznosabbnak találtam. Hozzuk ki a 
legtöbbet az SSH programból! Ez a cikk is az OpenSSH-n 
alapul, ezért ha esetleg valamilyen más változatot használnak, 
a trükkök kipróbálása előtt ellenőrizze a leírást. 


X11-átirányítás 

Az SSH-n keresztül X-es kapcsolatainkat titkosíthatjuk. 
Ráadásul nemcsak a forgalom lesz titkosított, hanem a távoli 
gép DISPLAY környezeti változója is a megfelelő értéket 
veszi fel. Ha tehát a helyi gépünkön X-et futtatunk, távoli 
X-alkalmazásaink varázslatos módon a mi képernyőnkön 
jelennek majd meg. 

Az X11-átirányítást az ssh -X gépnév paranccsal kapcsolhat- 
juk be. Az X11-átirányítást csak olyan gépekről használjuk, 
amelyeknek a rendszergazdájában megbízunk, ellenkező eset- 
ben az X11 alapú támadásokkal szemben sebezhetőkké válunk. 
Egy, az X11-átirányításon alapuló ügyes trükkel képeket jelenít- 
hetünk meg az xterm ablakokban. Futtassuk a beépített kép- 
nézővel ellátott w3m böngészőt a távoli gépen, figyeljük meg a 
w3m- img Debian csomagot vagy a w3m-imgdisplay RPM-et. 
Ezek az X11-átirányítás segítségével xterm ablakunk felett egy 
keret nélküli ablakot nyitnak. Ha levelünket szöveges ügyfél 
segítségével, távolról olvassuk SSH-n keresztül, ezzel a mód- 
szerrel ugyanabban az xterm ablakban megnézhetjük a benne 
rejlő képességeket. 


Beállításfájl 
Az SSH a -—/.ssh/config helyen keresi a felhasználói beállítás- 
fájlt. Ez például a következőképpen nézhet ki: 


ForwardX11 yes 
Protocol 2,1 


A ForwardX11 yes ugyanazt jelenti, mintha a -X kapcsolót 
adtuk volna meg a parancssorban. A Protocol sor adja meg 
az SSH-nak, hogy előbb az SSH2 rendszert használja, és ha 
nem megy, csak akkor lépjen vissza a SSH1-hez. Amennyiben 
kizárólag SSH2-t használunk, töröljük a , 1 részt. 

A beállításfájlunkban a Host utasítás alkalmazásával szaka- 
szokat is kialakíthatunk, amelyek csak bizonyos távoli gépek- 
hez való kapcsolódás során lépnek életbe. Hasznos beállításfájl- 
utasítás a User, amely a távoli gépen adja meg felhasználó- 
nevünket. Ha ssh -1 távolifelhasználó távoligép 
vagy ssh távolifelhasználógtávoligép alakban gyak- 
ran jelentkezünk be valamelyik gépre, érdemes a beállítás- 
fájlunkba illeszteni a következő sorokat: 
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Host távoligép 
ForwardX11 yes 
User távolifelhasználó 


Host " 
Forw ardXi11 no 


Mostantól csak a távoli gépet kell begépelnünk, ha a 
ForwardX11 képesség bekapcsolásával távoli felhasználóként 
akarunk bejelentkezni. Minden más esetben a ForwardX11 
legyen kikapcsolva, ahogy azt fentebb ajánlottuk. A csillag 
minden gépnévvel egyezőnek tekintendő, még azokkal a 
nevekkel is, amelyeket korábban a Host szakaszokban felso- 
roltunk, de mindig csak az első találat utasítását használja a 
rendszer. Az egyedi Host szakaszokat ezért beállításfájlunkban 
az általános Host szakasz elé tegyük. 

Az SSH rendszerbeállításfájllal is rendelkezik, amelynek neve 
/etc/ssh/ssh config. Az SSH a következő sorrendben gyűjti a 
beállításadatokat: parancssori kapcsolók, felhasználói beállítás- 
fájl, végül rendszer-beállításfájl. Az összes kapcsolót megtalál- 
hatjuk aman ssh config szövegében. 


Gyorsítsunk: tömörítés és kódolások 

Az SSH bármelyik kapcsolaton képes használni a gzip 
tömörítést. Az alapértelmezett tömörítés körülbelül 4Xx-es 
szövegtömörítésnek felel meg. A tömörítés különösen jól 
jöhet, ha például X-alkalmazást szeretnénk modemes vagy 
lassú hálózati kapcsolaton átirányítani. A tömörítést az 

ssh -C kapcsolóval vagy a Compression yes beállításfájlba 
illesztésével kapcsolhatjuk be. 

Egy másik sebességgyorsító módosítás lehet titkosító kódolá- 
sunk megváltoztatása. Számos régi rendszer alapértelmezett 
kódolása a háromszoros DES (3DE5), amely lassabb a Blowfish 
vagy AES kódolásnál. Az OpenSSH új változatai alapértelme- 
zés szerint a Blowfisht használják. A kódolást az ssh -c 
blowfish kapcsolóval állíthatjuk át. 

Beállításfájlunkban attól függően kell beállítanunk a kódo- 
lást, hogy SSH1 vagy SSH2 alapú rendszert használunk-e. 
Az SSHI esetében a Cipher blowfish, míg SSH2 alatt a 
Ciphers blowfish-cbc, aes128-cbc, 3des-cbc, 
cast128-cbc,arciour,assi9a-cbe,aesz5sb ebe 
alakot használjuk. 


Kapuátirányítás 

A kapuk a kiszolgáló különféle szolgáltatásait jelképező 
számok; például a 80-as kapu a HIIP-szolgáltatásnak, 

míg a 110-es kapu a POP3-nak felel meg. A szabványos 
kapuszámokhoz tartozó szolgáltatások listáját a /etc/services 
állományban találjuk. Az SSH gépünk bármelyik kapujáról 
képes adatokat átküldeni egy SSH-t futtató távoli gépre, 

s a forgalmat aztán a távoli kiszolgáló a másik gép tetsző- 
leges kapujára irányíthatja. De miért akarnánk mi ilyesmit? 
Két okból: a titkosítás kedvéért és a csövezett 

(tunelling) kapcsolatért. 


Titkosítás 

Egy csomó alkalmazás használ olyan protokollt, amelyben 
a jelszavak és az adatok egyszerű szövegként utaznak a 
hálózaton. Ilyen a POP3, IMAP SMIP és az NNIR Az SSH 
átlátszó módon képes őket titkosítani. legyük fel, hogy a 
levelezőprogramunk normál esetben a mail.example.net 
POP3-kapujára szokott kapcsolódni (110-es kapu). lovábbá 
tegyük fel, hogy a mail.example.net gépre ugyan az SSH-val 
nem tudunk közvetlenül belépni, viszont van azonosítónk 
a shell.example.net-en. Ilyenkor megmondhatjuk az SSH-nak, 
hogy titkosítsa a saját gépünk 9110-es kapuját (a számot 
tetszőlegesen választhatjuk meg), és a shell.example.net 
SSH-kiszolgálóját felhasználva küldje a mail.example.net 
110-es kapujára: 


ssh -L 9110:mail.example.net: 
5110 shell.example.net 


Azaz a helyi 9110-es kaput továbbítsd a mail.example.net 110-es 
kapujára a shell.example.net-re nyitott SSH-kapcsolaton keresztül. 
Ezután nincs más dolgunk, mint a levelezőprogramunknak 
megadni, hogy a helyi gépünk 9110-es kapujához kapcsolód- 
jon. Itt az adat titkosítódik, az SSH-kapun keresztül átkerül 

a shell.example.net-re, ahol visszakódolódik, végül a 
mail.example.net 110-es kapujára továbbítódik. Hasznos mel- 
lékhatásként a mail.example.net POP3-démonja azt fogja 

hinni, hogy minden forgalmat a shell.example.net-től kap. 


Csövezett kapcsolatok 

Az SSH képes a tűzfalon átívelő hídként működni - védje az 

a tűzfal akár a saját gépünket, akár a távoli gépet, netalán 
mindkettőt. Az egyetlen dolog, amire szükségünk van, egy 
ismert SSH-kiszolgáló a tűzfal másik oldalán. Például igen sok 
DSL és kábelmodemes cég tiltja a levelek küldését saját gépünk 
25-ös (SMIP) kapuján keresztül. 

Következő példánkban kábelmodemes kapcsolatunkon keresz- 
tül levelet küldünk cégünk SMIP-kiszolgálójáról. A példában 
felhasználtuk a mail.example.net nevű SMIP-kiszolgálón meg- 
lévő azonosítónkat. Az SSH-parancs a következő lesz: 


ssh -L 9025:mail.example.net: 
57525 mail.example.net 


Ezt követően levélküldő programunknak mondjuk meg, hogy a 
helyi gép 9025-ös kapuját használja levélküldésre. Ez a gyakorlat 
igen hasonlónak tűnik az előzőhöz, csak most a mail.example.net 
25-ös kapujára a mail.example.net-en keresztül a helyi 9025-ös 
kapuról nyitottunk csatornát. A tűzfal szemszögéből mindössze 
szabályos SSH-adatok utaznak a szabványos SSH-kapun (22) 
keresztül, köztünk és a mail.example.net között. 


Bináris adatok csövezése távoli héjprogramba 
Az SSH-n keresztül használt csövezés távoli héjprogramokba 
teljesen átlátszó módon működik. Figyeljük meg a következőket: 


cat myfi1le ] ssh userEédesktop 1lpr 


tar -cf —- source dir ] ssh userEdesktop 


ms at s dest. tár 
Az első példa a myfile állományt csövezi az a desktop nevű 


gépen futó 1pr programba. A második példa egy tarfájlt hoz 
létre, és a tartalmát a terminálra írja (mivel a tarfájl nevének 
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helyére egy kötőjelet írtunk), amit aztán átcsövezünk a desktop 
nevű gépre, és átirányítjuk egy fájlba. 


Távoli héjparancsok futtatása 

Az SSH segítségével nem feltétlenül kell felhasználói beavat- 
kozással (interactive) héjprogramot nyitnunk, ha mindössze 
csak a távoli program kimenetére vagyunk kíváncsiak. Például 
a következőt is megtehetjük: 


ssh felhasználóeggép w 
A fenti parancs felhasználóként lefuttatja a w parancsot a gép 
nevű gépen, majd megjeleníti az eredményt. Használhatjuk 


a parancsok önműködővé tételére is: 


"foreach Si (1 12) NN 
"ssh serverSi "w" ) 


perl -e 
(forint 


Ügyeljünk az SSH-parancs körüli fordított egyszeres idéző- 
jelekre (aposztróf). A fenti sor Perl segítségével 12 alkalommal 
hívja meg az SSH-t, mindannyiszor más-más távoli gépen fut- 
tatva le a w parancsot, kezdve a server1-től egészen a server12-ig. 
De minden egyes SSH-kapcsolat létrejöttekor be kell majd gé- 
pelnünk a jelszavunkat. Ha viszont továbbolvasunk egy kicsit, 
megtudhatjuk, hogyan kerülhetjük el a biztonság feláldozása 
nélkül a jelszógépelést. (Ugyanezt sokkal egyszerűbben és 
erőforrás-takarékosabban az alábbi héjprogaramocska is tudja: 
do ssh serverSi done 


for 1 in seg i1 12 : "w" ; 


—- Mészáros Gergely, a fordító. 


Utazzunk SSH Java Applettel 

Seregnyi ember szaladgál lemezen magával hordozva a 
PuITY-ot vagy valamilyen hasonló windowsos SSH-progra- 
mot, hátha utazásai során nem biztonságos gépet kell használ- 
nia. Ez a módszer azonban csak akkor működik, ha lemezről 
lehet futtatni a programokat. Igaz, a PUTIY programot a 
honlapjáról is letölthetjük és elindíthatjuk. 

Egy másik lehetséges megoldás, ha az előzőleg valamely 
honlapra felrakott SSH Java appletet böngészőből használjuk. 
Például kitűnő Java SSH-ügyfél a Mindterm, ennek nem 
üzleti célú felhasználása ingyenes. A programot a 

2 http:/www.appgate.com/mindterm oldalon találjuk meg. 


Összegzés 

Az SSH beállítása a trükkök alkalmazása során néhány helyen 
könnyen félresiklik. Számos hibát felderíthetünk az ssh -v 
kapcsolóval és a kimenet figyelésével. Kétségtelen, hogy a 
trükkök egyike sem nélkülözhetetlen az SSH használatához, 
viszont könnyen kerülhetünk olyan helyzetbe, amikor örülünk, 
hogy mégis ismerjük őket. Nem árthat meg, ha kipróbálunk 
közülük néhányat! 


MPE TOUKNAaN ZOOSEGÜGÜSZTÜTS ZETT ZESZANMA 


Daniel R. Allen (dacxcoder.com) 

1995 óta elfogult Linux-rajongó. Egy kitcheneri 
programtanácsadó cég, a Prescient Code 
Solutions elnöke Ontario és Ithaca, területén. 
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Kapcsoljuk össze otthonunkat és munkahelyünket virtuális magánhálózaton keresztül! 


dotcom-korszak boldog, szép napjaiban egy P2P- 
A programot fejlesztő, induló cég legelső alkalmazottja 

voltam. Mivel az intranetet és a fejlesztőkörnyezetet 
az alapjaitól kellett felépítenünk, mindenhol használhattuk a 
Linuxot. Mint tudjuk, a világ megváltozott, a dotcomok a dodó 
madár sorsára jutottak. Induló vállalkozásom is így járt, felvá- 
sárolta egy nagyobb vállalat, amely Windows-alapon fejlesztett. 
Bár az új cég elég engedékeny volt, így továbbra is Linuxszal 
dolgozhattam, de az ezzel kapcsolatos rendszergazdai fela- 
datok is teljesen rám hárultak. 
Egyetlen terület volt, ahol komoly nehézséggel kellett szem- 
benéznem: a VPN beállítása. A régi munkahelyemen minden 
fejlesztőnek volt bemenő SSH-kapcsolata a saját munkaállo- 
mására. Az új munkahelyemen nemcsak az SSH-kapukat zár- 
ták le, de a rendszeresített VPEN-megoldás sem volt Linux- 
barát. A tehetetlenség törvényéből fakadóan várható volt, 
hogy a több felületen is működőképes megoldások, például 
a FreeS/WAN, nem fognak egyhamar bevezetésre kerülni. 
Szerencsére a VIun, a régi munkahelyemen használt VPN- 
megoldás elég rugalmas volt ahhoz, hogy ebben a barát- 
ságtalan környezetben is helytálljon. 


Hogyan működik? 

A VIun úgy működik, hogy az IP-alagutazást észrevétlenül a 
meglévő csomagtovábbító programokon keresztül valósítja 
meg. A unixos moduláris szemléletnek megfelelően a VIun 
közvetlenül csak a csomagok alagutaztatásáért felel a két rend- 
szer között, és a meglévő hálózati segédeszközöket használja a 
teljes VPN-megoldás kialakítására. A hasonlat kedvéért képzel- 
jük el, hogy az otthoni és a munkahelyi hálózat két különálló 
vasúti hálózat. Minden számítógépnek egy állomás felel meg. 
A Linux-rendszermag vezérli a váltókat, így határozza meg, 
hogyan érik el a vonatok egyik állomásról a másikat. Ezeket a 
lehetőségeket a route programmal befolyásolhatjuk, így a 
végfelhasználó is adhat hozzá vagy távolíthat el állomásokat. 
A Linux-rendszermag képes a vonatok útvonalát megváltoz- 
tatni. Vasutaspéldánkhoz adjuk hozzá az internetet, a hatalmas 
vasúthálózatot. Az otthoni és a munkahelyi hálózatok aprócska 
nyúlványok ebben a rendszerben. Általában egyetlen állomás, 
a tűzfal vagy az átjáró rendelkezik közvetlen hozzáféréssel az 
internet vasúthálózatához. Ha egy másik állomás az otthoni 
vágányokról vonatot akar küldeni az internetre, először az 
átjáróállomásra kell továbbítania. Ezt az útvonal-módosítást, 
ami műszakilag az IP-álcázásnak vagy a hálózati címfordítás- 
nak felel meg, az iptables program vezérli. Az iptables 

a 2.4-es Linux-rendszermagban lévő Netfilter tűzfalkód felhasz- 
nálói térben futó fele. 

Hogyan illeszthető be a VIun a példába? Emlékezzünk, hogy 
az otthoni és a munkahelyi hálózatok egymástól elszigetelt 
vasúthálózatok. Otthonról általában nem mehet vonat a 
munkahelyre, mert a munkahelyi tűzfalállomás nem engedi át. 
A VIun segítségével virtuális sínpárt építhetünk két elkülönült 
hálózaton lévő állomás — például egy otthoni és egy munka- 
helyi gép -— között. A sínpár lefektetése után az állomásokon be 
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kell állítani az iotables-t és a routed-et, hogy az otthonról 
érkező vonatok szabadon elérhessék a munkahelyi rendszert, 
mintha csak egy munkahelyi gépről érkeztek volna. 


Szabályok és kikötések 

Most, hogy áttekintettük a VIun VPN-összetevőit, készen 
állunk a teljes megvalósítás vizsgálatára. A leghétköznapibb 
eset, amikor egyetlen távoli munkaállomást (az otthoni gépün- 
ket) kötjük össze a munkahelyi belső hálózattal a munkahelyi 
gépünkön keresztül. Az egyszerűség kedvéért feltesszük, hogy 
lehetséges SSH-kapcsolatot létesíteni otthonról a munkahelyi 
géppel, de az a gép egyébként nem érhető el az internetről. 
Tegyük fel, hogy az otthoni hálózat a 192.168.1.0/24 alhálózatra, 
a munkahelyi hálózat a 192.1683.5.0/24 és a 192.168.100.0/24 
alhálózatokra van beállítva. 

A VIun kiszolgálóalapú rendszer. A kiszolgálógép a megadott 
kapukon figyeli a bejövő kapcsolatokat. Az ügyfél kezdemé- 
nyezi az alagút létrehozását a kiszolgáló kapujára csatlakozva 
-— ebben a példában az otthoni gép az ügyfél és a munkahelyi 
gép a kiszolgáló. 

A VPN létrehozása azt jelenti, hogy a munkahelyi hálózat 
onnantól fogva csak annyira biztonságos, mint az otthoni 
hálózat. Emiatt az otthoni gépeket kötelező tűzfallal védeni, 
amire mindig fel kell rakni az összes biztonsági foltot, és 
behatolásvédelmi szempontból rendszeresen ellenőrizni 

kell. A másik nagyon fontos szabály, hogy soha ne hozzunk 
létre VPN-t a munkahelyi rendszergazdák tudta és bele- 
egyezése nélkül. 


Telepítés 

A VIun programot az ügyfélre és a kiszolgálóra is telepíteni 
kell, azaz az itt leírt folyamatot mindkét rendszeren végre 

kell hajtani. A folyamatot a Red Hat Linux újabb változatain 
próbálták ki. Ha a telepítés nem sikerül a terjesztéseden, küldj 
levelet a ryaneoryanbreen.com címre. Ezeket a válaszokat 
beépítem a 3 http:/www.ryanbreen.com/lvtun honlapon 
fenntartott terjesztésfüggő hibákat felsoroló állományba. 
Néhány terjesztés eleve tartalmazza a VIun-csomagot, 
úgyhogy elképzelhető, hogy megtakaríthatunk egy lépést, 

ha a csomagkezelővel telepítjük a VIun programot. 

A legtöbb VPN-megoldáshoz hasonlóan a VIun is igényli a 
rendszermag támogatását, ebben az esetben a TUN pont-pont 
hálózati illesztőprogramot. A TUN modul része az alaprend- 
szermagnak, úgyhogy valószínűleg nem kell rendszermagot 
fordítani hozzá. legyünk egy próbát az insmod tun parancs- 
csal (rendszergazdaként), amely megkísérli az illesztőprogram 
betöltését. Ha a modul nem található, töltsük le a legújabb 
változatot (jelenleg ez a tun-1.1) a 

2 http:/vtun.sourceforge.net/tun/index.html címről. 
Telepítsük: 


tar xzf tun-1.1.tar.gz 
cd tun-1.1 
su -c "make install 


Ha önműködően szeretnénk betölteni a TUN modult, amikor 
egy folyamat megkísérli elérni a virtuális alagúteszközt, akkor 
a következő sort adjuk a /etc/modules.conf állományhoz: 


alias char-major-10-200 tun 


Ezután állítsuk be és telepítsük a felhasználói térben futó 
vtund programot. A legújabb VIun-csomag a 

2 http://tun.sourceforge.net/download.html oldalról érhető 
el. Most forrásból telepítünk, de ha a terjesztésünk támogatja 
az RPM- vagy DEB-csomagokat, akkor nyugodtan telepítsük 
az előre lefordított változatot. A legújabb forráscsomag a cikk 
nyomdába adásának pillanatában a vtun-2.5.tar.gz. 

A fordítás a szokásos módon Zajlik: 


tar xzf vtun-2.5.tar.gz 
cd. vEÉUH-Z,.5 

. /configure 

make 
sú -c "make install" 

Egyes terjesztéseknél a beállítólépés sikertelen lehet, mert az 
LZO nincs telepítve. Az LZO egy tömörítő programkönyvtár, 
amelyet a VIun használ. 

A 5 http:/www.oberhumer.com/opensource/lzZo/download 
weboldalról tölthető le. Fordítsuk le és telepítsük az LZO-t, 
majd próbáljuk újra a VIun telepítését. 

A telepítés során a VIun a beállítóállományát a /usr/local/etc/ 
vtund.conf helyre teszi. Ez nagyon zavaró lehet, mert az ügyfél- 
nek és a kiszolgálónak mást-mást kell beállítani az alagútleíró 
részben. A félreértések elkerülése érdekében a vtund.conf állo- 
mányt nevezzük át vtund-client.conf, illetve vtund-server.conf 
névre. Ezt követően az indításkor kézzel adjuk meg a meg- 


ába gé 


szerint járunk el. 


A Vlun beállítóállománya 

A VIun beállítóállománya viszonylag egyszerű (lásd az 1. és a 2. 
listát — az utóbbi megtalálható az 51. CD Magazin/ VIun könyv- 
tárában). Az állomány három különálló részből áll. Az elsőben 
általános beállítások szerepelnek, például a kiszolgáló kapu- 
értelmezett munkamenet beállításai vannak, amelyek az alagút 
hálózati tulajdonságait írják le. Ezeket a tulajdonságokat szük- 
ség esetén egy adott alagút beállításánál felül lehet bírálni. 

Van egy alagútbeállító kapcsoló, amely különleges figyelmet 
igényel: ez a keepalive. A vállalati rendszergazdák gyakran 
alacsony tétlenségi időt engedélyeznek a tűzfalon keresztül 

a működő kapcsolatok számára. Ha az alagút a megadott 
időnél tovább tétlen, a kapcsolat időtúllépéssel megszakad. 

A keepalive engedélyezésével a VIun úgy kerüli meg ezt a 
gondot, hogy rendszeresen csomagokat küld az ügyféltől a 
kiszolgálóra, így meggyőzi a tűzfalat arról, hogy a kapcsolat él. 
A beállítások utolsó csoportja az adott alagút beállításait tartal- 
mazza. A beállítóállomány tetszőleges számú ilyen beállítást 
tartalmazhat, így több VPN kialakítása is lehetővé válik az 
ügyfelek és a kiszolgálók számára. Minden alagútbeállító cso- 
port egy névvel kezdődik. Én a my tunnel nevet választottam, 
de bármit megadhatunk. Minden alagút jelszóval védhető, de 
ezzel általában nem foglalkozunk, ha az alagút SSH-n keresztül 
jön létre. Az up és down részek az alagút felépülésekor, illetve 
lebontásakor végrehajtandó parancsokat tartalmazzák. 

Az 1. és 2. listán látható egyszerű beállítóállományok arra utasít- 
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7. lista Egyszerű vtund-client.conf 


aotians 1 
port 5000 


t Különféle programok elérési útja 
1NECGIME LŐ] VASI tokat ÁRTK letere inka kejás 


t Munkamenet alapértékei 
(e]ENKENST NK AN 
compress no; 
EIMETA YO o 
speed 0; 
alapértelmezettként 
keepalive yes; 
stat Ves; 


st Nimcs tömörítés 
s Az SSE úgyis titkosít 
? Légmnagyoldo sebesség 


my. tunnel ( 


pass  XXXXXXXX; t Jelszó 
type tun; t IP-alagút 
öroto tEös mr TCB fJorotokoll 
ONE 
Tt 10.3.0.íi z hamis alagűtcsazoló (otthon) 
$ 10.3.0.2 z hamis alagűtcsazoló 
— (munkahelyen) 
s 192.1686.5.0/24 z az 1. műumnkamelyai 
ss hálózat 
H.L9221689.100.50724 "csa 2. münkahelyi 
sz nál őzae 
killeeoraekej 
"zs 10.3.0.1l öoiantoporiat 10.3.0.2 mEuü 
Sol 
18 
down ( 
itcomtig "45 dowma? e 
ha 
b 


ják a VIun programot, hogy kapcsolatfelvételkor hozza létre az 
alagút csatolóit. A beállítóállományokban a 9090 minta jelenti az 
alagútcsatolót, így több alagutat is létrehozhatunk tetszőleges 
sorrendben. Az alagútcsatoló tényleges neve a ,tun" előtagból és 
egy számjegyből áll. Az első létrehozott alagút neve tun0. 


VIun VPN létrehozása 

Próbáljuk ki a gyakorlatban a VIun beállításáról tanultakat. 
Az 1. és 2. lista felhasználásával hozzunk létre egy egyszerű 
alagutat. A listák az 5 ítp.ssc.com/publ/lj/listings/issue112/ 
66/5.tgz címen megtalálhatók, ha nem szeretnénk begépelni 
őket. Mentsük a vtund-server.conf állományt a munkahelyi 
gép /usr/local/etc könyvtárába, illetve a vtund-client.conf 
állományt az otthoni gép /usr/local/etc könyvtárába. Miután 
a beállítóállományok a helyükre kerültek, mindkét gépen 
indítsuk el a VIun-folyamatokat. Rendszergazdaként indítsuk 
el a kiszolgálót a munkahelyi gépen: 


vtund -f /usr/local/etc/vtund-server.conf -s 
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3. lista Teljes vtund-client.conf 


OJDIE a ornstíki 
jpersessb0 00 ; 


t Különféle programok elérési útja 


előjerai gy iaknmkéj [dcionáa/ LEGOMT ILO 
firewall (Aslemáe / 1jotalo Les s 
route /sbin/route; 


t Munkamenet alapértékei 
default ( 


coemoress mos rt Nimcs tömöricés 
emcrYryviot mos Tt Az SSE úgyis tEitkosiíic 
speed 0; HEG náloyzelolklS ElhESS Ég 
t alapértelmezettként 
keepalive yes; 
stat ves; 
) 
my tunnel ( 
foziSiS RG SGGBEGEKE ENE 
työs tums t 1IP-alagút 
fjorgottoláeteios mr TCB florotokol 1 
Újóset 
Tt 10.3.0.i — hamis alagútcsatoló 
st e MOTV) 
vm L0.3.0.2 - hamis alagűtcsatoló 


s (munkahelyen) 
s L92.168.5.0/24 z az 1. műiankalmelyi 
s háLóőzat 
hp 1952.168.100.0724 2 a 2. műünkalhelyi 
sz hálózat 
köe e ojtakemáej 
KE cAIN( BERG BRETON 000 átt EK [fo 6 RT t LARA AK (0) HÁG VER 0) HEG RNKT Ta LáTTŐ1) 
zo Bs 
route "ada —met 192.168.5.0 mectmask 
Sze as and al) TÖW LO go ÜZ 


igGés c iterelelítea e ASS EZ EÁKSISSHKO 0 EK Hate Emateika 
SE a OS ÉT AZ ee 

jő 

down ( 
MEG OTnNetk es süáelto vin 
ToOUtS Idel - met 192.168.5.0 mexzmask 
apa S 2 We LOS 
routes "del -met 192.1683.I1009.0 metmesk 
RÉ Ne a a ONOS s 2 
ja; 

J 


A -s kapcsoló hatására a vtund kiszolgálóként indul, a kapcso- 
latokra az 5000-es kapun vár. A kiszolgáló eléréséhez el kell 
tudnunk érni az 5000-es kaput a munkahelyi gépen. Emlékez- 
zünk rá, hogy példánkban feltettük, hogy a munkahelyi gép csak 
SSH-n keresztül érhető el, ezért az SSH kaputovábbító képessé- 
gét kell használnunk a munkahelyi gép 5000-es kapujához való 
alagutazásra. Otthonról adjuk ki a következő parancsot: 


ssh mydesktop.work.com -L 5000:localhost:5000 
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A -L kapcsoló hatására az OpenSSH az otthoni gép 5000-es 
kapuját a munkahelyi gép 5000-es kapujára irányítja. 

Az otthoni gép 5000-es kapujára irányított kapcsolatok 
SSH-n keresztül észrevétlenül átalagutaznak a munkahelyi 
gép 5000-es kapujára. Az elrendezésnek további előnye az, 
hogy a VPN-es forgalom titkosítva van. 

Miután a munkahelyi gépen futó kiszolgáló elérhető az 
otthoni gépről, csak az marad hátra, hogy elindítsuk az 
ügyfelet. Rendszergazdaként az otthoni gépen futtassuk 

a következő parancsot: 


vtund -f /usr/local/etc/vtund-client.conf 
my tunnel localhost 


Amy tunnel kapcsoló megadja az ügyfélnek és a kiszolgálónak, 
hogy milyen alagutat kell létrehozni. Mindkét rendszer lekéri és 
futtatja a megfelelő beállítóállományokból amy tunnel részhez 
tartozó up bejegyzésben megadott parancsokat. Az utolsó kap- 
csoló, a localhost, megadja a VIun kiszolgáló gépnevét. Ebben 
az esetben a VIun kiszolgáló a localhost, mert az 5000-es 
kaput átirányítottuk az otthoni gépről a munkahelyi gépre. 

Ha az alagút sikeresen létrejött, akkor mindkét gépen megje- 
lenik az 1£config kimenetében a tun0 csatoló. Az otthoni 
gépnek az IP-címe 10.3.0.1 a tun0-n, a munkahelyi gépnek az 
IP-címe 10.3.0.2. A vonatos példára visszatérve, létrejött egy 
sínpár az otthoni és a munkahelyi gépek között, és most már 
irányíthatunk rá vonatokat. Bemutatásként hozzunk létre egy 
SSH-kapcsolatot az otthoni gépről a 10.3.0.2-re. 


Beüzemelés 

Van már egy működő alagutunk otthonról a munkahelyre. 

A következő lépésben a route és iptables programok 
segítségével be kell állítanunk, hogy az otthonról jövő csoma- 
gok a munkahelyi gépen keresztül álcázódjanak a munkahelyi 
hálózat felé. Szerencsére ez egyszerűen megtehető, csak egy 
pár sort kell hozzáadni beállítóállományokhoz az ügyfélen és 
a kiszolgálón, és újra kell indítani a vtund folyamatokat. 

A VIun a kapcsolat létrejöttekor végrehajtja a megfelelő 
route és iptables parancsokat. 

A vonatos példával elmagyarázva ez azt jelenti, hogy az 
otthoni állomásról minden munkahelyi hálózatra irányuló 
vonatot az újonnan létrehozott VIun-sínpáron keresztül kell 
küldeni. Kézzel ez így állítható be: 


route add -net 192.1683.5.0 netmask 
sza ake zők 0 úg L0s 3. Úsz 

route add -net 192.168.100.0 netmask 
sas 255. 25940 úWw 10.320 


A másik megoldás, hogy a 3. listán látható módon adjuk hozzá a 
parancsokat a vtund-client.conf állományhoz. A parancsok hatá- 
sára az iotables minden csomagot továbbít a tun csatolóról, és 
úgy álcázza őket, mintha a munkahelyi gépről indulnának. Meg- 
tehetjük azt is, hogy a 4. listán látható parancsokat adjuk hozzá a 
vtund-server.conf állományhoz, és újraindítjuk a kiszolgálót. 

A route és az iptables beállítása után az egész vállalati 
belső hálózat látszani fog otthonról. Böngészhetjük a belső 
webkiszolgálókat, kapcsolódhatunk a forráskód-kiszolgálóhoz, 
és megpróbálhatunk grafikus elemeket (például egy xterm-et) 
exportálni. Ezekre a célokra több mint elegendő a teljesítmény, 
és az SSH-alagút biztosítja, hogy a forgalom a kíváncsi szemek 
elől rejtve marad. 

Ha a kiszolgálót esetleg önműködően szeretnénk elindítani, 


4. lista Teljes vtund-server.conf 


éjet LONS 1 
bort o0 00; 


t Különféle programok elérési útja 


köme 6 latak / sbin/ iiKelotmkimkiket 
firewall / sbin/7 iiölkélolkése 
route / SO Hy szoke s 
) 
t Munkamenet alapértékei 
default ( 
G(oMjosEis simot HD Nőakeisőikornoraánés 
emcryot mos ZSZ STÉT teja zás ltek dos He 
speed 0; ? LegnaGgyalao sebesség 
t alapértelmezettként 
keepalive yes; 
stat ves; 
J 
my tunnel ( 
pass  XXXXXXXX; ? Jelszó 
zo cé t 1IP-alagút 
öroto tCIOs r TCB jörotokoll 
Új a 
Tt 10.3.0.1 - hamis aláasúűtcesatoló (otthnon) 
Tt 10.3.0.2 - bamis alagútcsatzoló 


— (munkahelyen) 
pr 102. t68 150724 S az otthoni hálözat 


kMilne(o nám 
IST (0 RAER 0 KEZÉT fr TÉT mk EK joo Hát tsztlt EK0 FR HRÁ(0) FÉGÁLAT NT] 
SZIATOK 

vovte "Jade -—-műmet 192.168.1L.0 metmask 


SS Ae KO FGJYAT SHE 


firewall "-t nat-A POSTROUTING -o 35 
—2z7 MASOÚERADE" a 
firewall "-AFORWARD -i1 23 -]j ACCEPT"; 
Jé 
down ( 
MEGO TnkEKE já St SöKe o yyakults 
route "del -net 192.168.1.0 netmask 
SSE Za KÖTVE ÁKOS LES 
JT 
J 


akkor a használt terjesztéstől függ a teendőnk. A VIun-forrás- 
csomag tartalmaz néhány indítóparancsfájlt a különböző 
terjesztésekhez - olvassuk el a Readme állományt, majd 
válasszuk ki a legmegfelelőbbet. 


Beállítások haladóknak 

Észrevehettük, hogy csak egyetlen otthoni gépnek volt hozzá- 
férése a munkahelyi intranethez. Az otthoni hálózat más 
állomásairól induló vonatok nincsenek átirányítva. Ez a meg- 
oldás egy hajszálnyival biztonságosabb, mert csökkenti a 
munkahelyi hálózatot fenyegető, az otthoni hálózatról eredő 
hibákból adódó veszélyeket. Ha az otthoni hálózat más gépei- 
ről is el szeretnénk érni a munkahelyi hálózatot, akkor egysze- 
rűen adjuk hozzá a megfelelő iptables-szabályokat a vtund- 
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client.conf állomány up részéhez. Ezt az érdeklődő olvasó 
gyakorlásképpen elvégezheti. 

A fenti megoldás tökéletesen működik, ha bármelyik munka- 
helyi gép elérhető SSH-n keresztül. Sajnos sok munkahelyen 
egyáltalán nem hagynak nyitva egy bejövő kaput sem. Pon- 
tosan ez volt a helyzet az új munkahelyemen is, de a 
rugalmassága átsegített ezen az akadályon is. A megoldás a 
szerepek felcserélése: a munkahelyi gép lesz az ügyfél, és az 
SSH-alagutat a munkahelyről kezdeményezzük. 


A megoldás akkor működőképes, ha az otthoni gépet a munka- 


helyünkről el tudjuk érni. A legtöbb széles sávú szolgáltató 
viszont dinamikus IP-címet oszt. A gond a dinamikus IP-kre 
kifejlesztett DNS-szolgáltatások egyikével áthidalható, például 
a Dyndns.org által nyújtottal. 

A legnagyobb hátrány a viszonylagos törékenység. Biztonságos 
környezetben az ügyfél nem indul el önműködően, mert az 
SSH-kapcsolathoz hitelesítés szükséges. Egy munkahelyi áram- 
szünet miatt könnyen kizáródhatunk. Ha kevésbé aggódunk a 
biztonság miatt, önműködővé tehetjük a bejelentkezést az SSH 
nyilvános kulcsos hitelesítése segítségével, ha nincs a kulcsnak 
jelszava, illetve az expect program parancsállományba 
építésével. Egyik módszert sem javaslom. 

Ha a munkahelyi gép szünetmentes tápegységre van kötve, 
akkor ritkán jön elő ez a gond. Az elmúlt hat hónapban, amióta 
ezt a megoldást használom, csak egyszer tartott olyan hosszú 
ideig az áramszünet, hogy a VPN-em ügyféloldala meghaljon 
tőle. A megoldás az otthoni hálózat oldalán is megbízható. 

A számítógép napokra is hálózati kapcsolat nélkül maradhat, 

a VPN újraindul, ahogy elindítjuk a vtun kiszolgálót, hála az 
ügyfél okos életbentartó és újrapróbálkozó képességeinek. 


Osszefoglalás 

A VIun képességeinek teljes ismertetése jóval meghaladná e 
cikk kereteit. Az itt bemutatott egyszerű megoldásokon kívül 
a VIun lehetővé teszi IP-n kívüli protokollok alagutaztatását is 
etherneten, PPP-n vagy SLIP-en keresztül. A VIun saját maga 
is képes titkosításra, tömörítésre és sávszélesség-formázásra, 


úgyhogy minden elképzelhető összeköttetéshez alkalmazható. 
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Reiser4: hatékonyan gyorstárazó fák tervezése 2£2. rész) 


A Reiser fájlrendszer negyedik változata a nagyobb teljesítmény 
érdekében jobban ellapítja a faadatszerkezetet, mint a harmadik változat tette. 
A leírtakból megtudhatjuk, hogyan Is fest ez a gyakorlatban. 


cikkünk a Reiser fájlrendszer felépítéséről szóló 
cikksorozatunk második része. Az első cikkben 
(Linuxvilág, 2003. március) az alapokat tárgyaltuk: 

a fákat, a csomópontokat és a cikkelyeket. Ebből a cikkből azt 
tudhatod meg, hogy miért jobbak a kiegyensúlyozott fák a 
kiegyensúlyozatlan fáknál, és miért jobbak a B- fák a B- 
fáknál, miközben a gyorstárazási alapelveket is megismered. 
Ezt követően arra is fény derül, hogyan alkalmazza ezeket az 
említett elemeket a Reiser fájlrendszer az adatbázis-rendsze- 
reknél már megismert BLOB-ok, vagyis nagyméretű bináris 
egységek esetében. Mindez azt sugallja, hogy a BLOB-ok 
csökkentik a belső csomópontok gyorstárazásának a haté- 
konyságát, mivel a fa így kiegyensúlyozatlanná válik. Azt is 
megtudjuk, hogyan tárol a Reiser fájlrendszer olyan szerke- 
zeteket, amelyek nagyobb méretűek egy csomópontnál, téve 
ezt anélkül, hogy a fa kiegyensúlyozatlanná válna. 

Elnézést az olvasóktól, hogy mindenkit ennyire megvárattam 
ezzel a cikkel — a késedelem oka a Halloweenkor esedékes 

2.6 miatti bővítésbefagyasztás volt, mivel akkortájt kellett 

a Reiser4-et gyorsan megbízható formába hozni. 


c 


Elágaztatás 

Az elágaztatási ütem (n) a csomópontok számát jelöli, ame- 
lyekre az egyes szintek csomópontjai mutatnak (1. ábra). Ha 
minden egyes csomópont az alatta lévő szinten n csomópontra 
mutathat, akkor a tetejéről elindulva a gyökércsomópont a 
következő szinten n számú belső csomópontra mutat, amelyek 
mindegyike n számú belső csomópontra mutat az azt követő 
szinten és így tovább. Az m szintű belső csomópont nm levél- 
csomópontra tartalmazhat hivatkozást, amelyek az utolsó 
szinten rendelkeznek elemekkel. Minél több adatot próbálsz 
tárolni egy fában, annál nagyobb mezőkre van szükséged a 
kulcsoknál, amikkel különbséget lehet tenni az elemek között, 
majd pedig az adott elem valamelyik része (egy bizonyos elto- 
lásnál) kijelölhető. Ez azt jelenti, hogy a kulcsaidnak nagyob- 
baknak kell lenniük, ennek következtében nő az elágazási 
szám (kivéve, ha a kulcsokat tömöríted, de ezzel a következő 
változat megjelenéséig még várni kell). 

Az 1. ábra első része egy négyszintű fát ábrázol, aminek az elá- 
gazási száma n — 1. Csupán négy darab csomóponttal bír, ezek a 
vörös gyökércsomóponttal indulnak, átlépve a sötétvörös, vagyis 
belső csomópontba, majd a kék gallycsomópontba, végül pedig 
a zöld levélcsomópontba, ami a tényleges adatot tartalmazza. 

A második négyszintű fa (amelynek az elágazási száma n — 2) 
egy gyökércsomóponttal kezdődik, amit két belső csomópont 
követ, amelyek mindegyike két gallycsomópontra mutat (ez 
összesen négy gallycsomópontot jelent), és mindegyikük tovább 
egy levélcsomópontba, ami összesen nyolc levélcsomópontot 
jelent. Végül pedig egy négyszintű, n — 3 elágazási számú fát 
láthatunk, melynek egy gyökércsomópontja, három belső csomó- 
pontja, 9 gallycsomópontja, és 27 levélcsomópontja van. 
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1. ábra Három darab négyszintű kiegyensúlyozott fa 


B-fa 
5,10, 25,...-kulcsok 
P - Blokk mutatók 
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2. ábra Egy B-fa 


5,10, 25, ... "kulcsok 
P . Blokk mutatók 


3. ábra Egy B--fa 


A B-t fák jobbak a B-fáknál 


A belső csomópontokban nemcsak mutatókat és kulcsokat 
lehet tárolni, hanem a kulcsokhoz tartozó elemeket is. Erre volt 
képes az eredeti B-fa algoritmus (2. ábra). Ezt követően találták 
ki a Bt fákat, amelyek csak mutatókat és kulcsokat tárolnak a 
belső csomópontokban, a kapcsolódó elemek pedig levélszin- 
ten tárolódnak (3. ábra). 


A B-t fák elágaztatási jobb a B-fákénál 

Az elágaztatás növelhető, ha a belső csomópontokban csak 
mutatókat és kulcsokat helyezünk el, továbbá nem hígítunk 
az elemek adataival. A nagyobb elágaztatásnak köszönhetően 
a belső csomópontok hatékonyabban gyorstárazhatók, mivel 
így kevesebb belső csomópontot kell kezelni. Az emberek erre 
gyakran azt mondják, hogy , de a B-fák elemeket gyorstáraz- 
nak, és az effajta gyorstárazás éppoly hasznos". Általánosság- 
ban azonban nem ez a helyes válasz. Ha az általánosságot 


vesszük alapul, a vita eldöntése még nehezebb lehet. De 
mielőtt erre jobban kitérnénk, tekintsük át a gyorstártervezés 
alapjait! Tételezzük fel a következőket: 


e Kétcsoportnyi elemmel rendelkezel: A-val és B-vel. 

e — legyük fel, hogy a két csoportból változó rendszerességgel 
szükségesek az elemek: bizonyos dolgokra gyakrabban van 
szükség, másokra ritkábban, és az egyes csoportba tartozó 
elemek idővel változhatnak. 

e Bizonyos elemeket kéznél tartunk, miután a korlátozott 
méretű gyorstárból előszedtük őket. 

e Az A csoportban található elemekhez olykor egy B csoport- 
beli elemet kell kötni, ami annyit tesz, hogyha szükségünk 
van egy elemre az A csoportból, akkor annak a B csoport- 
beli társára is szükség lesz. 


Így nő az A csoportból a gyakran használt elemek tárolásához 
szükséges gyorstár mérete. Ha erős kötődés van két szükséges 
elem között, amelyek a csoportok egyikében egymáshoz kötöt- 
tek, és ez a kötődés erősebb, mint a gyorstárazáshoz felhasznált 
erősforrásokon elért nyereség, ahol A és B az LRU (Least 
Recently used: újabban legkevésbé használt) algoritmusnak 
megfelelően gyorstárazódik, az hasznos lehet. Ha azonban 
nincs efféle kapcsolat, akkor kifejezetten rossz. Az LRU egy 
olyan algoritmus, amely az újabban kevésbé használt elemeket 
szórja ki a gyorstárból, így szabadít fel helyet. Az LRU külön- 
féle változatai az operációs rendszerek fejlesztésekor használt 
leggyakoribb gyorstárazási algoritmusok közé tartoznak. 

De várjunk csak! Mi történik akkor, ha a B csoportból is szük- 
séged van valamilyen elemre, s ezért jó lenne, ha innen is 
néhány elem a gyorstárba kerülne, tehát a B csoport valame- 
lyik szeletére lenne szükség? Ebben az esetben az a gond, hogy 
kapcsolat nélkül nem valószínű, hogy neked a B csoportból 
arra az elemre lesz szükséged, ami valamelyik A-beli elemhez 
kötődik. Ha kiválasztasz valamit a B-ből, akkor az a gyorstár- 
ban tárolódik, és ezáltal az LRU-ra épülő gyorstár hatékony- 
sága csökken, kivéve, ha a gyorstárazásért egy másik, legalább 
olyan jó algoritmus felel, mint az LRU. Amikor azt próbáljuk 
kiválasztani, hogy az A csoportnak megfelelően a B csoportból 
melyik elem gyorstárazása lenne ajánlatos, gyakran megesik, 
hogy az adott algoritmus nem olyan jó, mint az LRU, így 
megint bajban vagyunk. 

A dolgoknak kevésbé hatékony összekötése, amikre rendszer- 
telenül van szükségünk, a számítástechnikai világon kívül 
gyakori. Például tegyük fel, hogy szereted a pattogatott kuko- 
ricát és a szusit, de csak bizonyos napokon eszed őket és 
teljesen véletlenszerűen. Tételezzük fel, hogy a megnézendő 
filmeket is teljesen véletlenszerűen választod ki. Vegyük úgy, 
hogy a mozi megköveteli, hogy az adott, véletlenszerűen 
kiválasztott film esetében csakis pattogatott kukoricát ehetsz, 
és nem ehetsz szusit, amit pedig a sarki étteremben megkap- 
nál. Ez lenne a társadalmilag legelőnyösebb rendszer? legyük 
fel, hogy a hot dogok minősége az egyes hotdog-árusok között 
véletlenszerűen változik. Ha a legjobb moziban egy bizonyos 
este csak a moziban készült hot dogot eheted, és a külső árus- 
nál vásárolt hot dogot nem viheted be a mozi területére, az 
szerinted a társadalmilag legelőnyösebb? Előnyös-e ez számodra? 
A szorosan egymáshoz kapcsolódó dolgok összerendelése néha 
a teljesítmény szempontjából is előnyös. Számos fájlrendszer 
összerendeli a fájlméretadatokat a fájlnévadatokkal, ami úgy 
tűnik, hogy jól működik, legalábbis jobban, mint ahogyan az 
LRU működne. 

Gyakori hiba a gyorstárak tervezésekor, hogy olyan dolgokat 
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kötünk egymáshoz, amelyek egyébként nem állnak kapcso- 
latban, de ez még nem elég ahhoz, hogy megértsük, miért 
jobbak a B- fák a többinél. Belső csomópontok esetében 
egyetlen csomópontban több mutatót is tárolunk, ezáltal a 
mutatók nem külön-külön kerülnek a gyorstárba. Vitatható, 
hogy a mutatók és az általuk hivatkozott elemek szorosabban 
összefüggenek-e, mint több különböző mutató. Remélem, 

a leírtak valóban tanulságosnak bizonyulnak, azonban még 
mindig meg kell értenünk egy gyorstárazási alapelvet. 


Saját meghatározásom a gyorstár hőmérsékletére 

Legyen a gyorstár hőmérséklete egy olyan érték, ami azt 
határozza meg, hogy milyen gyakran férünk hozzá az adott 
területhez, megszorozva a lemezről való beolvasás költségével, 
végül elosztva a felhasznált bájtok számával. lalán észrevettél 
egy szándékos pontatlanságot az iménti meghatározásban: 
hogyan lehetnek a kisebb elemek forróbbak beolvasásuk tel- 
jesítnényigényességének következtében? A gyorstár-hozzá- 
férés hőmérsékletére egyéb meghatározások is elképzelhetők, 
jelen cikk esetében azonban ez tűnik a legmegfelelőbbnek. 

Ha két különböző típusú dolgot tárolunk egy csomópontban, 
amelyeknek különbözik az átlaghőmérséklete, akkor két külön 
csomópontba helyezésükkel a gyorstárazás hatékonyabbá tehe- 
tő. legyük fel, hogy R bájtnyi RAM áll rendelkezésre gyorstára- 
zásra, míg D bájtnyi lemezterületünk van. legyük fel, hogy 

a kérések nyolcvan százaléka a legutoljára használt dolgokra 
hivatkozik, ezek a csomópont H (vagyis forró) bájtjai. A na- 
gyobb teljesítmény érdekében a H-t az R-hez képest csökkent- 
jük. Ha a gyakran használt adatokat egyenletesen szétszórod, 
akkor nagyobb méretű gyorstárra lesz szükséged, és a gyorstár 
is veszít a hatékonyságából. 


Gyorstárazási alapelvek 

Ha növeljük a csomópontok közötti hőmérséklet-eloszlást, akkor 
kisméretű gyorstárból is nagyobb teljesítmény tudunk kihozni. 
Ha kétfajta dolognak eltér a hőmérsékletátlaga, akkor külön 
csomópontokban helyezzük el őket, így növelve a rendszer 
egészében a hőmérséklet-eloszlást. 

Ha minden egyéb egyenlő, és két különböző típusú dolgot 
tárol több példányban egyetlen csomópontban, akkor a 
gyorstár hatékonyabbá tehető, ha több különböző csomó- 
pontban osztjuk el őket. 


Mutatók csomópontokra 

A csomópontokra hivatkozó mutatók gyakran hívódnak meg az 
általuk elfoglalt bájtok számához hasonló gyakorisággal. Vegyük 
azt az esetet, amikor mindhárom átjáró esetében mutatókat kell 
használni, amelyek az alsóbb szinten lévő csomópontokat érik 
el, és kisebbek, mint azok a csomópontok, amikre hivatkoznak. 
Ha csak csomópontmutatókat helyezünk el, és a kulcsokat a 
belső csomópontokra korlátozzuk, a csomópontok sűrűsége nő. 
Mivel a mutatókra méretükhöz képest négyzetesen több alka- 
lommal van szükség, mint a fájlok tartalmát tároló többi elem- 
re, a mutatók és a cikkelyek adatai között jelentős a hőmér- 
sékletátlaguk közötti különbség. 

A korábban tárgyalt gyorstárazási alapelveknek megfelelően 

a kétfajta hőmérséklet-átlagú csoport (a mutatók és az elemek 
adatai) elágaztatása növeli a gyorstár hatékonyságát. 

Most talán azt kérdeznéd, hogy miért nem a valódi hőmérsék- 
letadatok alapján végezzük az elágaztatást a típus szerinti 
helyett? Azért, mert a típus csak a hőmérséklettel függ össze? 
Azt tesszük, amit a legegyszerűbb kódolni, nem csak a hőmér- 
séklet-eloszlást véve alapul. 
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Néhány fatervezet úgy rendezi át a fát, hogy a magasabb hő- 
mérsékletű elemek magasabban vannak, mint az alacsonyabb 
hőmérsékletű mutatók. Az elemadatok és a csomópontmutatók 
közötti hőmérséklet-különbség olyan mértékű, hogy az effajta 
tervezeteket én nem tartom versenyképesnek, emellett a meg- 
valósításuk is bonyolultabb. A négyzetes nagyságú átlaghő- 
mérséklet-különbséget véve alapul azt gyanítom, hogyha téve- 
dek is, ez mégsem elegendő ahhoz, hogy foglalkozzunk vele. 
A többi fatervezet mintegy oldaljegyzetként megemlíti, hogy 

a vándorló elemek hőmérséklet szerint magasabban helyez- 
kednek el a fában. Ha valaki pusztán csak a hőmérséklet 
szerint válogatna, de a szintek változtatása nélkül, az talán 
tényleg hatékonyabb lenne. Amennyiben valaki nem rendel- 
kezne versenyképes tervezési alapokkal az elemek egymás 
körüli csoportosítására (ami néhány alkalmazás esetében igaz), 
és ha valaki az elemeket ahelyett, hogy egyenként férne 
hozzájuk, csomópontonként próbálja elérni, akkor érdemes 
lenne egy csomópont-újracsomagolót birtokolnia, hogy az 
elemadatokat hőmérséklet szerint csomópontokba rendezze. 


A B-t fák jobban végzik a gyorstárazást, mint a B-fák 

A B- fák külön csomópontokban osztják el a mutatókat és az 
adatokat. A fában csomópontokra hivatkozó mutatók általában 
forróbbak, mint a fában található egyéb dolgok (mintegy négy- 
zetes arányban). Mindazonáltal a korábban tárgyalt gyorstá- 
razási alapoknak megfelelően a mutatók és az adatok szétvá- 
lasztása hatékonyabb gyorstárazást eredményez. A számító- 
gépiparban a B-- fákat a gyakorlatban jobbnak ismerik el, mint 
a B-fákat, mint ahogyan ezt a felvázolt elmélet is megjósolja. 
Az is elfogadott bölcsességnek minősül, hogy a kiegyensúlyo- 
zott fák hatékonyabbak a kiegyensúlyozatlan fáknál. Egyelőre 
azonban még nem elfogadott, de a fentiek alapján mégis meg- 
jósolható, a BLOB-ok - ahogyan az adatbázisipar hívja őket — 
rossz hatással vannak a teljesítményre. Erről és arról, hogy 
mik azok a BLOB-ok, hamarosan bővebben is szót ejtek. 


Mit takar a kiegyensúlyozott? 

Ezt a fogalmat többféle, egymással kapcsolatban nem álló 
dologra is alkalmazzák, mint ahogyan a kiegyensúlyozott fák 
szakirodalma is megemlíti. E dolgok két legismertebbike a 
kiegyensúlyozott magasságok és a kiegyensúlyozott területek, 
amelyek a fa csomópontjaiban találhatók. Sajnálatos módon 
ezek a különféle meghatározások sok félreértést okoznak a 
szakirodalom olvasóinak - ezt én megpróbálom elkerülni. 

A magasság-kiegyensúlyozott fák azok, amelyek esetében 

a gyökértől elindulva a levélcsomóponthoz vezető minden 
útvonal azonos hosszúságú. A hosszúság alatt a gyökércsomó- 
ponttól a levélcsomópontig bejárandó csomópontok számát 
értjük. Például az első ábrán a fa magassága 4, míg a 4. ábrán a 
fa magassága 3, míg az egy csomópontból álló fa magassága 1. 
A legtöbb algoritmus a magasságmérés elvégzése céljából a fát 
csak a tetején növeli, ezáltal a fa sosem esik ki a magassági 
egyensúlyból. 

Az 5. ábrán egy kiegyensúlyozatlan fa látható. A fa kezdetben 
talán kiegyensúlyozott volt, de a különböző törlések 
következtében elvesztette néhány belső csomópontját. Illetve 
az is elképzelhető, hogy azért vált kiegyensúlyozatlanná, mivel 
anélkül lettek hozzá új elemek adva, hogy ügyeltek volna a 
kiegyensúlyozottságra. 

A hagyományos adatbázismódszerekkel, ha egy csomópontnál 
nagyobb elemet szeretnénk tárolni, akkor ezt BLOB-okban 
tehetjük meg, ami azt eredményezi, hogy a fa kiegyensúlyozat- 
lan lesz. A BLOB-ok jelentik az általános módszert arra, hogy 
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5. ábra Egy kiegyensúlyozatlan fa 
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6. ábra Négyszintű fa egy BLOB beszúrása után 


nagyméretű elemeket tároljunk; működésük lényege pedig az, 
hogy a csomópont mutatókat tartalmaz azokra a csomópon- 
tokra, amelyek az elemet tartalmazzák. Az elemet tartalmazó 
csomópontokat levélcsomópontoknak hívják, ez minden "B"" 
fára jellemző. 

A 6. ábrán egy BLOB-ot szúrtunk be egy négyszintű fa levél- 
csomópontjába, ami annyit tesz, hogy a levélcsomópontban 
mutatókat helyeztünk el, amelyek a fájladatokat tartalmazó 
részekre hivatkoznak. A Reiser fájlrendszer 3-as változatának 

a fái így működtek. 

Ez elég jelentős változás, amit mégis a teljes adatbázis-közösség 
elfogadott. Az itt leírt gyorstárazási alapelveknek megfelelően 
így csökkenthető a mutatók és elemadatok elágaztatása, de ez 
ront a gyorstár hatékonyságán. Emlékezzünk rá: a gyorstárazás 
alapelvei szerint ez rossz elgondolás. lehát mindazon okokból 
kifolyólag, amelyek szerint a B-t fák jobbak a B-fáknál, a Reiser 
fájlrendszer 4-es változatának fái is jobbak a 3-as változat 
fáinál, bár nem olyan nagy mértékben. 

Hogy ezt jobban megértsük, a 7. ábrán egy Reiser4-es fa látható 
3-as elágazási számmal, egy BLOB-bal az első szintű levélcso- 
mópontban, valamint egy erre hivatkozó mutatóval a hármas 
szintű gallycsomópontban. Ebben az esetben a BLOB mezői 
folyamatosan helyezkednek el. A tárterület érdekében ez a 
többi levélcsomópont alatt helyezkedik el, de a hozzá tartozó 
mutató egy második szintű gallycsomópontban található, mint 
minden más elem mutatója is. 

Bár elfogadott dolog, hogy a B-t fák jobbak a B-fáknál, az még- 
sem olyan elterjedt, hogy a BLOB-ok rosszul vannak megter- 
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7. ábra A Reiser4 a BLOB-okat 
az első szintű levélcsomópontokban tárolja 


vezve, és az ezzel kapcsolatos tévhit jellemző az adatbázisiparra. 
Gray és Reuter azt mondja, hogy a külső memória keresésének 
az a jellegzetessége, hogy az egyes oldalak számát az általános 
(vagy leghosszabb) keresési úton csökkentsük, méghozzá 
olyan módon, hogy egy tetszőleges keresési útra csökkentjük 
az egyes oldalak számát, kisebbíti a valószínűségét annak, 

ha valamit közvetlenül a lemezről szükséges beolvasni (lásd 

a Kapcsolódó címeket). 

Ezzel a magasság-kiegyensúlyozottság hatékonyságáról szóló 
elemzéssel az a bajom, hogy nem árulja el, hogy egy mérsé- 
kelten kiegyensúlyozott fával is lehet boldogulni - feltéve, 
hogy nem növeled meg nagymértékben a belső csomópontok 
számát. A gyakorlatban a kiegyensúlyozatlan fák csakugyan 
több belső csomóponttal rendelkeznek. A legtöbb mérsékelten 
kiegyensúlyozatlan fa esetében valamennyivel több memórián 
belüli lépdelésre van szükség a fában, ugyanakkor az [/O-ter- 
helés nagymértékben nő, mivel több belső csomópontot kell 
feldolgozni, amiket — mivel így már túl sok csomópont van — 
nem lehet a gyorstárban tárolni. 

De ha az összes BLOB-ot egyetlen helyen tárolnánk a fában, 
akkor ezáltal a csomópontok száma nem nőne jelentős mérték- 
ben, mivel az adatoknak minden más levélnél alacsonyabb 
szinten tartásából adódó teljesítménycsökkenés kis mértékű 
lenne. A fa bejárásának a költsége azonban — a RAM sebessé- 
gétől függően — valamelyest nőne, de nem jelentős mértékben. 
A Reiser4-féle megközelítés nem az egyetlen lehetséges módja 
a belső csomópontszám csökkentésének. A BLOB-ok 
elágaztatása valószínűleg alapvetően megoldaná a gondot, ami 
azoknak a tervezőknek a hibájából keletkezik, akik a magasság- 
kiegyensúlyozott fák meghatározásának a lényegét figyelmen 
kívül hagyják. Valószínűleg az is nagy hatással lenne az [/D- 
teljesítményre, ha elkülönítenék azokat a BLOB-okat, amelyek 
nem állnak szoros kapcsolatban a fával. A Reiser4 esetében 
nem akartam arra korlátozni a fát, hogy az elemeket csak a 
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méretük szerint ágaztassa el egymástól. De egy napon valaki 
majd biztos megpróbálja, és remélhetőleg elmondja nekünk, 
hogy mit tapasztalt. 

A Reiser4 visszatér a magasság-kiegyensúlyozott fák klasszikus 
meghatározásához, vagyis minden egyes levélcsomóponthoz 
az út hossza egyenlő nagyságú. A Reiser4 nem színleli, hogy 

a nagyméretű elemeket tároló csomópontok nem a fa részei, 
annak ellenére sem, hogy a fa mutatókkal hivatkozik rájuk. 

A Reiser4 a Reiser fájlrendszer 3-as változatához képest csök- 
kenti a belső csomópontok és a mutatókat tartalmazó csomó- 
pontok számát. A 188 megabájtos Linux-rendszermag 2.4.1-es 
változatának forrásának tárolásához a ReiserFS v3 1629 
csomópontot használt fel, ehhez a Reiser4-nek csak 164 csomó- 
pontra van szüksége. Ennek eredményeképpen a mutatók és 
csomópontok tárolásához szükséges RAM-mennyiség a 
Reiser4-nél döbbenetes mértékben mérséklődött. 


Megjegyzés a cikk következő részeihez 

A soron következő cikkekben megtudjuk, hogy miért lénye- 
gesen jobb a Reiser4 teljesítménye, mint a ReiserFS v3-é, még 
teljesen üres gyorstár mellett is. Megtudjuk, hogy miért jobbak 
a táncoló fák, mint a helyigényes kiegyensúlyozott fák, és azt 
is, hogy miként kezeljük a tranzakciókat olyan módon, hogy 
ugyanakkor nagymértékben csökkentjük a kétszer leírandó 
adatok mennyiségét. 


Lgtnérx JoUrnat ZO0S Tmnajus eTO ESZA 


Hans Reiser (reiseronamesys.com) 
1979-ben csatlakozott az UC Berkeley-hez, és ,Rendsze- 
rezésre" szakosodott, ami egy egyéni ágazat. Az elméleti 
modellek fejlődését tanulmányozza. 
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Jim Gray és Andreas heuter Iransaction 

Processing: Concepts and lechnigues. Morgan 

Kaufmann Publishers, Inc., 1993. — Ez egy régi, 

de jó könyv a tranzakciókról. Elérhető a 

2 http:/Avww.mkp.com/books. catalog/ 
catalog.asp?ISBN-—1-55860-190-2 címen. 
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Processzorhoz kötés 





Bizonyos folyamatok egyetlen processzorhoz kötése 


egy új rendszerhívás segítségével. 


Linuxnak az a képessége, hogy a segítségével folya- 
matokat köthetünk egyetlen processzorhoz, már 
nagyon régóta várt tulajdonság volt. Ezt a képességet 
processzorhoz kötésnek nevezzük, ami azt jelenti: ,ez a folya- 
mat csak ezen a bizonyos processzoron futhat", vagy pedig 
,ezek a folyamatok csak ezeken a processzorokon futhatnak, 
de a nullás processzoron nem". Az ütemező ennek megfelelően 
betartja a kikötéseket, és a folyamatok csak a számukra kijelölt 
processzorokon fognak futni. 

Más operációs rendszerek, mint például a Windows NI, már 
régóta biztosítanak processzorhoz kötéssel kapcsolatos rend- 
szerhívásokat. Ennek következtében a Linuxban is egyre 
inkább kívánatossá vált, hogy ilyen képességekkel bővítsék. 
Végül a 2.5-ös rendszermagban megjelentek a folyamatok pro- 
cesszorhoz kötését meghatározó és lekérdező rendszerhívások. 
A cikkből kiderül, hogy miért szükséges, hogy ismerjük a 
processzorhoz kötéssel kapcsolatos képességeket, és később azt 
is megtudhatjuk, hogyan használhatjuk ki ezeket az új képes- 
ségeket. Ha nem vagy programozó, vagy csak akad egy olyan 
programod, amit nem vagy képes módosítani, bemutatok 
neked egy segédeszközt, amellyel egy adott PID-del rendel- 
kező folyamatod processzorhoz való kötését állíthatod be. 
Végül pedig megvizsgáljuk a processzorhoz kötéssel kapcso- 
latos rendszerhívások megvalósítását. 


Gyenge és erős processzorhoz kötés 

Kétféle processzorhoz kötés létezik: a gyenge és az erős. 

A gyenge, amit természetes kötésnek is hívunk, az ütemezőnek 
azt a tulajdonságát hivatott jellemezni, hogy egy folyamat ese- 
tében az ütemező mindig arra törekszik, hogy az adott folyamat 
a lehető leghosszabb ideig ugyanazon a processzoron fusson. 
De ez pusztán próbálkozás, mivel ha bármi közbejön, a folya- 
mat rögtön költözik is a másik processzorra. A 2.5-ben található 
O(1) ütemező kiváló természetes kötési képességekkel bír, 
amelynek a 2.4-es rendszermag pontosan az ellenkezője, ahol 
is a processzorhoz kötés meglehetősen gyenge volt. Ha ez a ter- 
mészetes kötés gyenge, létrejön a pingponghatás. Ez annyit 
tesz, hogy az ütemező a folyamat minden egyes meghívásakor 
más-más processzoron futtatja a folyamatot. Az 1. táblázatban 


1. táblázat A pingponghatás 


Tsz AT [mg [emrt 7] eu Tur 


2. táblázat A jó processzorhoz kötés 


OsosS A CRUOCAVO EV CAO 
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egy rossz processzorkötésű ütemezés látható; a 2. táblázat azt 
mutatja, hogyan néz ki a jó processzorkötésű ütemezés. 
Ezekkel ellentétben az erős processzorkötés az, amit a pro- 
cesszorkötéssel kapcsolatos rendszerhívások biztosítanak. Az 
erős kötés kötelesség, amit az ütemezőnek kötelező érvénnyel 
be kell tartania. Ha például egy folyamat a nullás procesz- 


szorhoz van kötve, akkor minden esetben csakis azon futhat. 


Miért van szükség a processzorhoz kötésre? 

Mielőtt részletesebben megismerkednénk az új rendszerhívá- 
sokkal, előtte tisztázzuk, hogy egyáltalán miért van szükség 
rájuk. Elsődleges előnyük az, hogy a gyorstárazás teljesítménye 
növelhető. Mint mondtam, az O(1) ütemező erősen törekszik 
arra, hogy a folyamatok egy processzoron maradjanak, és lehe- 
tőség szerint ott is tartja őket. De bizonyos teljesítményigényes 
helyzetekben — mint amilyen mondjuk egy nagy adatbázis-ki- 
szolgáló futtatása, vagy egy temérdek szállal dolgozó Java-ki- 
szolgáló — nagyon fontos lehet, hogy ezt a processzorhoz való 
kötést a legszigorúbban kezeljük. A több processzoros számí- 
tógépek keményen megdolgoznak azért, hogy a processzorok 
gyorstára érvényben maradjon. Az adatok egyszerre csak az 
egyik processzor gyorstárában találhatók meg, máskülönben 

a gyorstár elveszíti összehangoltságát, és ez bizonytalansághoz 
vezet azt illetően, hogy melyik processzor gyorstára tartalmazza 
a rendszermemóriának leginkább megfelelő másolatot. Ennek 
következtében, ha az egyik processzor egy sornyi adatot helyez 
el a gyorstárában, akkor az összes többi processzornak a helyi 
gyorstárában érvénytelenítenie kell azt a bizonyos sort. Ez az 
érvénytelenítés meglehetősen kellemetlen és költséges. De az 
igazi gond akkor jelentkezik, ha egy folyamat ugrál a procesz- 
szorok között, ami érvénytelenítések sorozatával jár, és a szük- 
séges adat sosem található meg a gyorstárban. Így a gyorstár 
hibázási gyakorisága nagyon nagyra nő. A processzorhoz kötés 
ettől véd meg, és ezáltal növeli a teljesítményt. 

A processzorhoz kötés másik nagy előnye első pillantásra a 
fentiek egyenes következményének tűnik. Ha több szál fér 
hozzá egyszerre ugyanahhoz az adathoz, akkor előnyös lehet, 
ha a szálak egy processzoron futnak. Így biztosított, hogy a 
szálak nem érvénytelenítik a különböző processzoron lévő 
adatokat, és nem okoznak hibákat a gyorstárban. Ez ugyanak- 
kor SMP-rendszerek esetén csökkenti a többszálúságból követ- 
kező teljesítménynövekedést. A gyorstárazásból nyert teljesít- 
ménynövekedés talán megéri azt a veszteséget, amit a szálak 
egymás utáni végrehajtása következtében el kell szenvednünk. 
A harmadik és egyben utolsó előny valós idejű, illetve idő- 
érzékeny alkalmazások esetében lehet számottevő. Ebben a 
megközelítésben minden egyes rendszerfolyamat a rendszer- 
ben bizonyos processzorokhoz van kötve. Egy bizonyos alkal- 
mazás pedig a maradék processzorokhoz. Általános esetben 
egy kétprocesszoros rendszerben ez a bizonyos alkalmazás egy 
processzorhoz van kötve, míg minden más folyamat a másik 
processzorhoz. Így biztosított, hogy erre a bizonyos alkalma- 
zásra összpontosul az adott processzor összes figyelme. 


Az új rendszerhívások elérése 

A rendszerhívások meglehetősen újak, ezért egyelőre nem min- 
den rendszeren érhetők el. Legalább 2.5.8-pre3-as változatszámú 
rendszermag és 2.3.1-es glibc szükséges (bár a 2.3.0-s glibc támo- 
gatja a rendszerhívásokat, egy hibát is magában rejt). 2.4-es 
rendszereken az új rendszerhívások még nem érhetők el, de 

egy folt már rendelkezésre áll, ami a 5 http:/www.kernel.org/ 
pub/linux/kernel/people/rml/cpu-affinitycímről tölthető le, illetve 
megtalálható az 51. CD Magazin/Processzor könytárában. 

A frissebb terjesztések közül több is magában foglalja ezeket 

a szolgáltatásokat. A Red Hat 9-ben például már a rendszermag 
és a glibc is tartalmazza a rendszerhívásokhoz szükséges támo- 
gatást. A valós idejű megoldások közül például a MontaVista 
Linux támogatja az új felületet. 


Kötődési maszkok 

A legtöbb rendszeren - beleértve a Linuxot is — a processzorhoz 
kötést bitmaszkok segítségével lehet beállítani. A bitmaszk n 
számú bitből áll, ahol az egyes bitek be-, illetve kikapcsolt 
állapotától függnek bizonyos szolgáltatások. Például a pro- 
cesszorhoz kötést (32 bites számítógépeken) egy 32 bites bit- 
maszk határozza meg. Az egyes bitek azt jelölik, hogy az adott 
folyamat kötve van-e egy bizonyos processzorhoz vagy pro- 
cesszorokhoz. A biteket jobbról balra kell számolni, a 0-s bittől 
a 31-es bitig, és ennek megfelelően a nullás processzortól a 

31. processzorig. Például: 


TELLETT LT TELET ETT TETT TAT LILI a 4 294 967 24295 


Ez az alapértelmezett processzorhoz kötési maszk minden 
folyamat esetében. Mivel minden bit be van kapcsolva, 

a folyamat bármelyik processzoron futhat. 

Ugyanakkor, ha a bitmaszk 


004000000000000000000000000000000L1 z 1 


akkor sokkal szigorúbb megkötések érvényesek. Minek utána 
csak a 0. bit van bekapcsolva, a folyamat csak a nullás pro- 
cesszoron futhat, vagyis a kötési maszk a folyamatot a nullás 
processzorhoz köti. Remélem, érthető. 

Mit jelent a követező két maszk tízes számrendszerben 
értelmezve? Mi történik, ha ezt a két maszkot egy folyamat 
kötési maszkjaként használjuk fel? 


104000000040000000000000000000000 
00000000000000000000000000000011 


Az első maszk 2 147 483 648-cal egyezik meg, mivel a 31. bit 
van bekapcsolva, és a folyamatot a 31. processzorhoz köti. 

A második bitmaszk értéke 3, és a folyamatot a nullás és az 
első processzorhoz köti. 

A Linux processzorkötési felülete a fentiekhez hasonló 
bitmaszkot alkalmaz. A C nyelv azonban sajnos nem 
támogatja a bináris állandókat, így mindig a decimális vagy 
hexadecimális, azaz tízes vagy tizenhatos számrendszerbeli 
állandókat kell használni. A fordító talán figyelmeztetni 
fog, ha olyan nagy állandót próbálsz használni, amelyik 

a 31. processzorhoz köti a folyamatot, de ne aggódj, 
működni fog így is. 


Az új rendszerhívások használata 


Az új rendszermag és glibc esetén az új rendszerhívások 
használata meglehetősen egyszerű: 
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Htinclude csched.hsz 


long 
sched setaffinity(pid t pid, unsigned int len, 
unsigned long ?tuser mask ptr); 


long 
sched getaffinity(pid t pid, unsigned int len, 
unsigned long ?tuser mask ptr); 


Az első rendszerhívást arra használjuk, hogy egy folyamat 
kötéseit beállítsuk, míg a második a már beállított kötéseket 
kérdezi le. 

Mindegyik rendszerhívás estében a PID kapcsoló annak a 
folyamatnak a PID-jét jelenti, amelynek a tulajdonságait le 
akarod kérdezni, vagy változtatni akarsz rajtuk. Ha a PID 
nulla, akkor a hívó folyamatra vonatkoznak a beállítások. 

A második kapcsoló a processzorkötési maszkban található 
bitek számát jelöli, amely jelenleg 4 bájt (32 bit). Ez a kapcsoló 
azért szükséges, mert ha a jövőben a rendszermagban változni 
fog az erre a célra fenntartott bitek száma, akkor a már 
elkészült programok az új környezetben is helyesen fognak 
működni. Nem lenne jó, ha meglévő programjaink egyszer 
csak működésképtelenné lennének. A harmadik kapcsoló egy 
hivatkozást tartalmaz, ami magára a bitmaszkra mutat. 
Nézzük csak meg, hogyan kérdezhetjük le egy folyamat 
processzorhoz kötési bitmaszkját: 
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unsigned long mask; 

unsigned int len - sizeof(mask) ; 

if (sched getaffinity(0, len, §mask) c 0) ( 
perror("sched getaffinity") ; 

return -1; 


3 


printf("a processzorkötési maszkom: 
sz081lxWwn", mask) ; 


Afféle kényelmi szolgáltatásként a visszaadott bitmaszk AND- 
olva van a rendszerben található működőképes processzorok 
bitmaszkjával, így biztosan csak a működőképes processzo- 
rokhoz tartozó biteket látjuk bekapcsolva. Például egy egypro- 
cesszoros rendszer a fenti hívásra mindig 1-gyel tér vissza 

(a 0. bit kivételével minden bit nulla). 

A maszk beállítása éppen ilyen egyszerű: 


unsigned long mask —- 7; 

—0/xr processors 0, 1, and 2 "/ 
unsigned int len - sizeof(mask) ; 

if (sched setaffinity(0, len, §mask) c 0) ( 
perror("sched setaffinity") ; 


) 


A példában a folyamatot a rendszerben lévő első három 
processzorhoz kötjük. Ezt követően meghívhatod a 

sched getaffinity () függvényt, hogy megbizonyosodj 
róla, a fenti példa valóban működött-e. Mivel tér vissza a 
sched getaffinity ( ) , ha valójában csak két processzor- 
ral rendelkezel? Mivel tér vissza, ha csak egy processzorral? 
A rendszerhívás sikertelen, ha a bitmaszkban megjelölt 
processzorok legalább egyike nem létezik. A nullás maszk 
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7. lista A bind forrása 


[docAuthor e ee zs szer llostácinesis onos es szides 
-; az alkalmazások orocssszorzaoz köczésémek 
xX beállítására. 


4 
ttdefine . GNU SOURCE 


Fimamclude zstöllib. he 
Frimelüde zzstelio.v lhhs 
Friaelüde 2cschedi.lhs 


dat maeilalimt arzgce, char rargyil?) 
1 

unsigned long new mask; 

Na Saten c eMKorngáketktalineteikes 


unsigned int len - sizeof(new mask) ; 
jödnG et föld; 
JA MAS TE 


a jorSmáaskEES eteleratat 
KS élGJESát es otet Ké ödlknmersíeáltne 
EG OI; 

return -1; 


jönd z atollazgvIil] ) ; 
sscanit(arogvi2]; "808al1-", Emew mask) ; 


it (sched getaffi1nity(pid, len, 
scuz mask) z 0) 1 
perror ("sched getaftiilnity") ; 
return -1; 


fa TekTEt ölte atá steel Más ro Hl] MP CAKTEKT att táttegy zását or (0 KAB Kérték 
jomkeleKetjkalnemsike ii 


meine ellés Eg MEKEKTMn kát o nk eltsáátlkeitató 
—97§8new mask)) í( 
perror ( "sched. setaftainity") ; 
return -1; 


ELESEN SelMtS EE EEMN KN ESZA (ő o nkeiteselkenató 
seu mask) z 0) ( 
perror ( "sched getaffiilnity") ; 
return -1; 


DELET" Did "őd s néw:-attindt/s 
S lBea 
fonkelKett ásának 
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mindig sikertelen hívást eredményez. Csakúgy, ha a 
7. processzorhoz szeretnél kötni egy folyamatot, és nincs hét 
processzorod, a rendszerhívás ugyancsak sikertelen lesz. 
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A rendszerben minden folyamat processzorkötési maszkja 
lekérdezhető, azonban a maszk csak azokban a folyamatokban 
változtatható meg, amelyeknek te vagy a tulajdonosa, illetve 
bármely folyamat bitmaszkját megváltoztathatod, ha rendszer- 
gazdai jogosultságokkal rendelkezel. 


Égy eszközt akarok! 

Ha nem vagy programozó, illetőleg nem vagy képes módosí- 
tani a forrást, akkor is megváltoztathatod a folyamatok kötési 
tulajdonságait. Az első listában egy egyszerű parancssoros 
eszköz forráskódját találod, amellyel bármely folyamat kötési 
maszkját egyszerűen beállíthatjuk, ha tudjuk a folyamat PID- 
jét. Mint említettem, ehhez neked kell lenned az adott folyamat 
tulajdonosának, vagy pedig rendszergazdai jogosultságokat 
kell birtokolnod. 

Az eszköz használata egyszerű, ha megtanulod a tízes 
számrendszerbeli kifejezésmódot: 


bind pid maszk 


legyük fel, hogy egy kétprocesszoros rendszerünk van, 
amelyben az 1600-as PID-del futó Ouake-folyamatot a második 
processzorhoz szeretnénk kötni. Egyszerűen csak a következőt 
kell begépelnünk: 


bind 1600. 2 


Legyünk igazán ravaszok 

Az előző példában a Ouake-et a rendszerünkben található 
egyik processzorhoz kötöttük. Hogy igazán gyors képet 
kapjunk, a rendszerünkben minden más folyamatot a másik 
processzorhoz kell kötnünk. Ezt megteheted kézzel is, 
vagy ha írsz egy trükkös parancsfájlt, de egyik sem igazán 
hatékony. Ehelyett használd ki, hogy a processzorhoz kötés 
a fork ( ) során öröklődik, vagyis egy folyamat minden 
gyermeke ugyanahhoz a processzorhoz fog kötődni, mint 
a szülője. 

Ennek a legtisztább módja, ha magát az init-et dolgozzuk 
meg egy kicsit, olyanformán, hogy a kívánt processzorkötési 
maszkot a rendszermag parancssorán keresztül adjuk át. 
Célunkat azonban egyszerűbben is elérhetjük, anélkül, hogy 
módosítanunk kellene vagy újra kellene fordítanunk az 
init-et. Helyette egyszerűen megszerkeszthetjük a rendszer- 
indító parancsfájlt. A legtöbb rendszeren ez a parancsfájl a 
/etc/rc.d/rc.sysinit vagy a /etc/rc.sysinit fájlok egyike, amit az 
init először futtat le. Helyezzük el a bind példaprogramot 
a /bin könyvtárban, és az rc.sysinit elejéhez adjuk hozzá a 
következő két sort: 


/bin/bind 1 1 
/bin/bind SS 1 


Ezek a sorok az init-et (aminek a PID-je 1) és az éppen 
futó folyamatot a nullás processzorhoz kötik. Minden 
jövőbeli folyamatnak ezek a folyamatok lesznek a szülői, 
így örökölni fogják a kötési maszkokat. Ezt követően a saját 
folyamatodat (legyen ez egy valós idejű nukleáris irányító 
rendszer vagy a Ouake) a másik processzorhoz kötheted. 
Ezt követően minden folyamat a nullás processzoron fog 
futni, kivéve a saját folyamatunkat és annak gyermekeit, 
amelyek az egyes processzoron futnak. Ez azt jelenti, 
hogy így a teljes processzor csak a mi saját folyamatunkat 
fogja kiszolgálni. 


Rendszermagbeli processzorkötés megvalósítása 

Jóval azelőtt, hogy Linus felvette volna a processzorhoz kötési 
rendszerhívásokat, a rendszermag már támogatta és figye- 
lembe vette a processzorhoz kötési maszkokat. Nem létezett 
azonban semmilyen felület, amin keresztül ezeket a maszkokat 
a felhasználó módosíthatta volna. Minden folyamathoz tartozó 
maszk a task struct szerkezetben tárolódik unsigned 
1ong-ként, cous allowed néven. A task struct szer- 
kezetet a folyamat leírójának nevezzük. Ez tárol minden adatot 
az egyes folyamatokkal kapcsolatban. A processzorkötési 
felület egyszerűen csak kiolvassa és módosítja a 

cpus. allowed változót. 

Bármikor, ha a rendszermag egy folyamatot át akar költöztetni 
egy másik processzorra, először ellenőrzi, hogy az adott folya- 
mat futhat-e azon a másik processzoron. Ha a másik procesz- 
szorhoz tartozó bit nincs bekapcsolva, akkor a processzor a 
folyamatot nem helyezi át. Ezen túlmenően, ha a procesz- 


A Schedutils ütemezővel kapcsolatos eszköztár: 
2 http://tech9.net/rml/schedutils. A csomagban meg- 


található a taskset nevű program, amellyel hatékonyan 
állítgathatjuk, a folyamatok processzorhoz kötését. 
Processzorhoz kötési foltok a rendszermaghoz és a 
glibc-hez: 38 http:/Awww.kernel.org/pub/linux/kernel/ 
people/rml/cpu-affinity 





szorhoz kötési maszk megváltozik, és a folyamat éppen egy 
számára nem engedélyezett processzoron fut, akkor a folyamat 
soron kívül áthelyeződik egy számára engedélyezett pro- 
cesszorra. Ez biztosítja, hogy egy folyamat csak a számára 
engedélyezett processzoron kezdheti meg a futását, illetve csak 
olyan processzorra költözhet át, amelyen nincs tiltva a futása. 
lermészetesen, ha csak egy processzorhoz van kötve a 
folyamat, akkor nem költözik sehova. 


Összegzés 

A 2.5-ösben megjelent processzorhoz kötési felület — és egyéb 
helyekre átültetett változatai — egyszerű, de mégis hasznos esz- 
közt kínálnak arra, hogy meghatározhassuk, hogy az egyes 
folyamatok mely processzoron fussanak. A többprocesszoros 
géppel rendelkező felhasználók biztosan örülni fognak, hogy 
újabb lehetőség teremtődött arra, hogy rendszerüket még ha- 
tékonyabbá varázsolhassák, vagy arra, hogy a legfontosabb valós 
idejű alkalmazások mindig kapjanak processzoridőt. De az 
egyprocesszoros számítógéppel rendelkező felhasználóknak sem 
kell magukat mellőzve érezniük, ők is használhatják az új rend- 
szerhívásokat, de ezáltal sem tesznek szert túl sok haszonra. 
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Az OpenlLDAP segítségével az összes alkalmazás kényelmes közös címtárat használhat. 
Helyes beállításával a hálózat biztonsága nemhogy csökken, hanem nőni fog. 


felhasználóval, de nem szeretnénk minden felhaszná- 

lónak teljes értékű fiókot létrehozni a kiszolgálón. Inkább 
valamiféle központi felhasználóhitelesítő szolgáltatást kellene 
használni, ami más célokra is jó lehet. Ha már itt tartunk, szük- 
ség lesz egy állandó elérésű (online) címjegyzékre szervezetünk 
levelező- és csoportmunkaprogramjai számára. Ezenkívül 
tegyük fel, a felhasználóknak titkosítóeszközökre is szükségük 
van, amelyek X.509-es tanúsítványokat használnak, valamint az 
egész szervezet számára kezelik a digitális tanúsítványokat. 
Elképzelhető, hogy létezik egyetlen szolgáltatás, ami mind a 
négy igényt ki tudja elégíteni? Az LDAP képes erre, sőt többre 
is. A nyílt forrás közössége abban a szerencsés helyzetben 
van, hogy rendelkezésére áll egy szabad, megbízható és teljes 
értékű LDAP-kiszolgáló és -ügyfél, ami a legtöbb Linux-ter- 
jesztésnek része: ez az OpenLDAR 
Az egyetlen hátrány, hogy az OpenLDAP egy bonyolult 
szörny. Értelmes használatához még több rövidítést és elvont 
elképzelést kell megismernünk a szokásos Unix-trükkökön 
kívül. Felszerelkezve a következő néhány hónapban megjelenő 
folytatással és egy kis elhatározással, nagyhatalmú LDAP-iste- 
nek lehetünk, akik egyszerre több vasat tartanak a tűzben, és 
a hálózatunk egyszerre lesz biztonságosabb és könnyebben 
használható. lapasztalataim szerint a , biztonságosabb" és az 
,egyszerűbben használható" rendszer ritkán valósítható meg 
egyszerre, ezért is lelkesedem azért, hogy ebben a rovatban 
végre bemutathatom az OpenLDAPtt. 


Az LDAP alapjai 


Dióhéjban összegezve: az LDAP címtárszolgáltatást nyújt, azaz 
egy központi adatbázisban érhetők el az emberek, csoportok és 
a szervezetet alkotó más elemek adatai. Mivel minden szerve- 
zet különböző lehet, és nem feltétlenül ugyanazokat az adato- 
kat tartják lényegesnek, a címtárszolgáltatásnak rugalmasnak 
és testreszabhatónak kell lennie. A megoldás ezért a feladat 
jellegéből adódóan bonyolult. 

A címtárszolgáltatásra létezik egy protokoll, az X.500. Az X.500-at 
nagy és összetett szervezetek nagy léptékű címtárszolgáltatásai- 
ra tervezték. Ennek megfelelően az X.500 önmagában annyira 
nagy és bonyolult protokoll, hogy pehelysúlyú változata, az 
LDAB amit az REC 1777 ír le - és gyakorlatilag az X.500 protokoll 
részhalmaza -, sokkal inkább elterjedt, mint az eredeti X.500. 

Az X.500 és az LDAP nyílt protokollok, miként a TPC/IP; egyik 
sem önálló termék. A protokollt valamilyen programnak kell 
megvalósítani, ez lehet magmodul, kiszolgálódémon vagy ügy- 
félprogram. A TCP/IP-hez hasonlóan nem minden LDAP-meg- 
valósítás egyforma, még csak nem is feltétlenül képesek együtt- 
működni egymással (módosítás nélkül). Most egy bizonyos 
LDAP-megvalósításról lesz szó, az OpenLDAP-ról, de tudnunk 
kell, hogy léteznek más programok is, amelyek szintén megva- 
lósítják az LDAP-t. Például ilyen a Netscape Directory Server, a 
Sun ONE Directory Server és bizonyos korlátokkal a Microsoft 
Active Directory a Windows 2000 Serverben. 


T együk fel, hogy IMAP-kiszolgálót üzemeltetünk rengeteg 
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Szerencsére az LDAF-t bővíthetőre tervezték. Ha az egyik 
környezetben létrehozunk egy LDAP-adatbázist, az cseresza- 
batos lesz más LDAP-megvalósításokkal is, egyszerűen csak 

be kell állítanunk az adatbázis rekordformátumát vagy sémáját. 
Ez a téma a következő hónapban kerül sorra. Ennek köszönhe- 
tően gond nélkül futtathatjuk az OpenLDAP-kiszolgálót 
Linuxon, és a címjegyzéket elérhetővé tehetjük, mondjuk egy 
Netscape Communicatort futtató Mac-felhasználó számára is. 


Az OpenLDAP heszerzése és telepítése 

Az OpenLDAP hasznos és fontos eszköz, ennek következtében 
minden jelentős Linux-terjesztésnek része. Általában több 
csomagra bontják szét: az egyik a kiszolgálódémont, a másik az 
ügyfélprogramokat, a harmadik a fejlesztéshez szükséges 
programkönyvtárakat tartalmazza. Ez a cikk az LDAP-kiszol- 
gáló felállítását tárgyalja, így magától értetődő, hogy terjeszté- 
sünk OpenLDAPt-kiszolgáló csomagját telepíteni kell. Ezen- 
kívül telepítsük az OpenLDAP futásidejű programkönyvtárait, 
ha azok nem részei a kiszolgáló csomagjának. Azt gondolhat- 
nánk, hogy az OpenLDAP ügyfélprogramjainak telepítése 
kihagyható egy olyan kiszolgálón, ahol nincsenek helyi fel- 
használók, és az LDAP-műveletek a hálózaton keresztül fognak 
zajlani. Ez sajnos nem így van, kimondottan javasolt az ügyfél- 
programokat is feltelepíteni, mert sokat segíthetnek a rendszer 
kipróbálásában és a hibakeresésben. 

Red Hat alatt az OpenLDAP a következő csomagokból áll: 
openldap (OpenLDAP-programkönyvtárak, -beállítóállományok 
és a leírás); openldap-clients (OpenLDAP-ügyfélprogramok és 
-parancsok); openldap-servers (OpenLDAP-kiszolgálóprogra- 
mok); valamint az openldap-devel (fejlécállományok és prog- 
ramkönyvtárak fejlesztők számára). Bár a csomagok legtöbb 
függősége teljesen érthető (például glibc), két szükséges csomag 
talán még nincs telepítve: a cyrus-sasl és cyrus-sasI-md5, ezek 
az LDAP hitelesítő műveleteit hivatottak közvetíteni. 

SuSE alatt a következő RPM-ekben helyezkedik el az OpenLDAP: 
openldap2-client (az n1 könyvtárban a SuSE 7.3 és 8.0 esetén); 
openldap2 (ebben az OpenLDAP-programkönyvtárak és a 
kiszolgálódémonok csücsülnek, és az n2 könyvtár részét képe- 
zik); openldap2-devel (a SuSE 7.3-ban az n2-ben található, a 
SuSE 8.0-ban az n4-ben érhető el). A Red Hatnél a már említett 
cyrus-sasl csomagot mindenképpen telepítsük fel, ami a sec1 
könyvtárban helyezkedik el. 

A 7.3-as és 8.0-s terjesztésekben a SuSE az OpenLDAP 1.2-es 
változatát is közreadta a 2.0-s mellett. Mindenképpen a 2.0-s 
csomagokat telepítsük, hacsak nincs különleges okunk az 
OpenLDAP 1.2 futtatására. Ez a tanács nem vonatkozik a Red 
Hat- és a Debian-terjesztésekre, mert ezek kizárólag az 
OpenLDAP 2.0-t használják. 

A Debian 3.0-s (Woody-) terjesztésben a megfelelő deb-csoma- 
gok a következők: libldap2 (OpenLDAP programkönyvtárak a 
Debian libs könyvtárából); s1lapd (az OpenLDAP-kiszolgáló a 
net könyvtárból); és az Idap-utils (OpenLDAP-ügyfélparancsok 
szintén a net könyvtárból). Ezenkívül még a libsas[7 


7. lista A /etc/openldap/slapd.conf testreszabott része 


database ilkellon 

S aleáK 157 ! deswiremonkevs , cdesoig " 

iaGols AT "cn-1ldapguy , dc-wiremonkeys, 
sudezorsejk 
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2. lista A slappasswd parancs 


[rootémydirserver openldapl] 
t slappasswd -h (SSHA) 
New passwojgazelókskteseőkásst sk 
Re-enter new password: 
(SSHAJloJhhíiíDajRcÍicDwwalt6o0ske8goj 80d 


KEKEKXKXKXKEK 


programkönyvtárra is szükség van a Debian libs könyvtárából. 
Amennyiben kedvenc terjesztésünk nem tartalmazza az 
OpenLDAP bináris csomagjait, vagy a legújabb OpenLDAP-ból 
szükségünk van egy adott tulajdonságra, amelyik nincs benne 
terjesztés OpenLDAP-csomagjában, vagy testreszabott Open- 
LDAP-csomagot szeretnénk, még mindig lefordíthatjuk az 
OpenLDAP hivatalos honlapjáról (3 http:/www.openldap.org) 
letölthető forrást. 


A slapd beállítása és elindítása 

Az OpenLDARP fő kiszolgálódémonjának a neve slapd, és az 
OpenLDARP telepítése után az első feladatunk ennek beállítása. 
A beállítások elsősorban a /etc/openldap/slapd.conf állomány 
szerkesztésével végezhetők el. 

A 5 http:/www.openldap.org/doc/admin20/guide.html címen 
megtalálható , OpenLDAP 2.0 Administrators Guide" kitűnően 
elmagyarázza a slapd elindításának és futtatásának kezdőlé- 
péseit a 2. fejezet 8. pontjától kezdve. A dokumentum a címtár- 
szolgáltatásokat és az LDAP fogalmait írásunknál nagyobb 
mélységben tárgyalja. 

Menjünk végig a lépéseken, hogy biztosan jól sikerüljön a kez- 
dés. Az első teendő a slapd.conf szerkesztése — szemléltetésül 
tekintsük meg az 1. listát. Láthatjuk, hogy a slapd.conf jelleg- 
zetes Linux-beállítóállomány: minden sora egy kapcsolónevet 
tartalmaz, amit egy érték követ. Az 1. listán szereplő első kap- 
csoló, a database azt adja meg, hogy milyen adatbázisháttér- 
rel kívánjuk az OpenLDAP-t használni. Általában a legjobb az 
1ldbm-et választani, ami a gyors dbm adatbázis-formátumot 
használja, de a she11 (egyéni héjprogramhátterek) és a passwd 
(a /etc/ passwd használata háttérként) szintén érvényes beállítás. 
Az 1. listán a következő kapcsoló a suf fix, amely meghatá- 
rozza, hogy milyen lekérdezések illenek erre az adatbázis-meg- 
határozásra. Az itt megadott végződés a wiremonkeys.org, ame- 
lyet az LDAP nyelvén balról jobbra értelmezett tartományelem- 
(dc) kifejezések sorozataként adunk meg. Más szavakkal, ha egy 
LDAP-ügyfél a cn-bubba , dc-wiremonkeys , dc-org meg- 
különböztető nevű (dn) gépet keresve lekérdezi a példakiszol- 
gálónkat, akkor mivel a dn vége dc-wiremonkeys , dc-org, ez 
az adatbázis fog ráilleni. A megkülönböztető nevekről többet 
tudhatunk meg a , Gyorstalpaló az X.500-as nevezéktanról" című 
írásból (az 51. CD Magazin/ LDAP könyvtárában található). 
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Az 1. lista következő két bejegyzése az LDAP-adatbázis felü- 
gyeletével kapcsolatos; a rootdn és a rootpw azt a felhasz- 
nálónév és jelszópárost adja meg, amelyet a helyi vagy távoli 
parancsoknak kell megadniuk, ha felügyeleti műveletet akar- 
nak végrehajtani az LDAP-adatbázison. Érdekes módon ez a 
bejegyzés csak erre a célra használatos. Nem jelenik meg a 
szabályos LDAP-adatbázis lekérdezésekben. 

Ez felveti azt az ellentmondást, hogy akkor milyen módon 
lehet hitelesíteni azokat a műveleteket, amelyek a hitelesítési 
(LDAP) adatbázis feltöltéséhez szükségesek. Később, ha már 
feltöltöttük az LDAP-adatbázist valódi adatokkal, az egyik 
felügyeleti fióknak, és töröljük a rootdn és rootpw bejegy- 
zést. Ezt a lépést egy későbbi írásban tárgyalni fogjuk; pillanat- 
nyilag a rootdn és a rootpwis megfelel. 

Nagyon rossz ötlet a rootpw értékét egyszerű szövegben 
tárolni. Ehelyett a slappasswd parancsot kell használni, ami 
a jelszó kódolt formáját állítja elő, miként a 2. lista is mutatja. 
Láthatjuk, hogy a slappasswd bekéri a jelszót, és a kódolt jel- 
szót a -h kapcsolóval megadott algoritmus szerint előállítja és 
kiírja a képernyőre. A -h után kapcsos zárójelben kell megadni a 
kívánt algoritmus nevét. A lehetséges választék a slappasswd(8) 
súgóoldalon fel van sorolva. A slappasswd kimenetét közvet- 
lenül bemásolhatjuk a slapd.conf állományba, én is pontosan ezt 
tettem az 1. lista rootpow értékének létrehozásakor. 

Visszatérve az 1. listához, a következő érték a címtár meghatá- 
rozásában a könyvtár. Nem meglepő módon ez azt adja meg, 
hogy a helyi állományrendszerben melyik könyvtárban legyen 
az LDAP-címtár létrehozva. Mivel a /var a megszokott helye a 
növekvő állományoknak, mint a naplók vagy az adatbázisok, 
az 1. lista a /var/lib/Idap értéket tartalmazza. Létező könyvtárat 
kell megadni, és az OpenLDAP felhasználójának és csoport- 
jának - általában 1dep és 1dap - tulajdonában kell lennie. 

A jogosultságokat állítsuk a 0700 (-rwx-————- ) értékre. 
Műszaki értelemben ennyi elég az elinduláshoz: az Idap 
indító-parancsfájljával próbáljuk meg elindítani a slapd 
démont. Ez leggyakrabban a /etc/init.d/lIdap, de terjesztésen- 
ként különböző lehet. Nyugodtan adjunk hozzá bejegyzéseket 
az LDAP-adatbázishoz az Idapadd parancs használatával 

— a korábban említett eljárás megmutatja, hogyan. 

Mielőtt a hálózaton keresztül kezdenénk el kezelni és lekér- 
dezni az LDAP-adatbázist, be kell állítani a ILS-titkosítást. 

Ez fontos, mert az OpenLDAP által használt egyszerű hitelesí- 
tési eljárás a hitelesítési adatokat titkosítás nélkül küldi át a 
hálózaton. Sajnos elfogyott a rendelkezésemre álló hely, ezért 
ez a téma a jövő hónapra marad. Aki nem tud addig várni, az 
olvassa el Vincent Danen Using OpenLDAP for Authentication 
írását a 5 http:/www.mandrakesecure.net/en/docs/Idap- 
auth.php címen, bár ez bizonyos tekintetben a Mandrake-et 
helyezi középpontba. Szintén tárgyalni fogom az LDAP-adat- 
bázis szerkezetének meghatározásával kapcsolatos megfon- 
tolásokat, és az LDAP-adatbázis létrehozásának a módját. 
Addig is sok szerencsét! 
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témákkal foglalkozó szerkesztője, biztonsági 
tanácsadó a Minnesota állambeli Minneapolisban 
található Upstream Solutions LLC Inc.-nél. 
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Ismerjük meg a Monót! 


A Mono haszna például abban áll, hogy segítségével 
a Linux képessé válik a Microsoft .NET rendszerével való munkára. 


mennyiben írtunk már valaha Linux-munkafelületen 
AA futtatható programot, vagy legalább megvizsgáltuk a 

lehetőségét, akkor ismert előttünk a nyelvi kötéseknek 
az a sokasága, ami a különböző grafikus felületek eszközkész- 
letéhez rendelkezésre áll. A Linux grafikus felületére való prog- 
ramírásnak ez az egyik erőssége: nem vagyunk egy adott progra- 
mozási nyelvhez hozzáláncolva. Sajnos hamarosan azt is észre 
kell vennünk, hogy a különböző nyelvi kötések az APTI igen el- 
térő készültségi fokával bírnak. Az egyik nyelven használt esz- 
közkészlet egy másik nyelven esetleg még nincs támogatva - ez 
a ,soknyelvűség" egyik hátulütője. Egy API karbantartásához 
szükséges munka mennyisége minden egyes nyelv esetén nö- 
vekszik. Az eredeti API megváltoztatása vagy frissítése esetén 
a változást minden egyes nyelvi burkolón végig kell vezetni. 
Most pedig képzeljünk el egyetlen GUI-eszközkészletet, ami 
bármilyen programozási nyelvből anélkül elérhető, hogy API- 
burkolót kellene használnunk. Egy olyan eszközkészletről van 
szó, ami minden őt használó programozási nyelvnek ugyanazt 
a szolgáltatást nyújtja. 
A Mono számos egyéb mellett ezzel a képességgel is rendel- 
kezik, ezáltal teremtve meg felhasználója számára a nyelvfüg- 
getlenséget és a nyelvek közötti párbeszéd lehetőségét. 


A Mono története dióhéjban 

A Mono története körülbelül két évvel ezelőtt kezdődött 

a Ximian nevű, Linux-programokra szakosodott cégnél. 

A Ximian leginkább a Ximian Desktopról, az Evolution 
naptár- és levelezőprogramjáról, a Red Carpet frissítőrend- 
szerről és a vakbuzgó műszaki igazgatóról, Miguel de Icazá- 
ról ismert. Felismerve néhány, az utóbbi időben napvilágot 
látott szabványban rejlő lehetőséget, Miguel de Icaza elké- 
szítette azt a programprototípust, amely később a Mono- 
projektben teljesedett ki. 

De mik voltak azok a szabványok, amik szemet szúrtak Miguel 
de Icazának? Nem titok, hogy ez az ECMA-334 és az ECMA- 
335 volt, amelyek a Microsoft .NE! fejlesztői felület alapját 
képező technológia leírását tartalmazzák. Ennél a pontnál 
hangsúlyoznunk kell, hogy lényeges különbség van a .NET 
fejlesztői felület és az általánosan használt ,. NET" kifejezés 
tartalma között. A Microsoft-termékek és szolgáltatások széles 
körét — operációs rendszereket, fejlesztői eszközöket, hálózati 
szolgáltatásokat és alkalmazásokat - illetik a tágabb értelemben 
használt .NET kifejezéssel. Mi ennek a .NET-nek csak egy 
bizonyos részével foglalkozunk. 

2000 októberében a Microsoft, a Hewlett-Packard és az Intel 


Rövid bevezetés a CZ-be 


A Cs magas szintű objektumközpontú programozási nyelv, amelyet 
a CLI (Common Language Infrastructure, általános nyelvi alap) 
kiegészítésére terveztek. A tervezői csapat élén Anders Hejlsberg 
(ismert Turbo Pascal- és Delphi-fejlesztő), Scott Wiltamuth és 

Peter Golde állt. 

Első pillantásra a Cs sok mindenben hasonlít a Javára. Bár a 
parancsformátum szempontjából hasonlóak, a Cs számos olyan 
lehetőséggel is rendelkezik, amivel a Java nem. A szolgáltatások 
némelyike közvetlenül a C-t 1 -ból származik, ilyen a túlterhelés 
(operator overloading), a felhasználó által meghatározott átalakí- 
tások (user-defined conversions), igazi szabályos tömbök és hivat- 
kozás szerinti értékátadás (pass-by-reference). A többi tulajdonság, 
mint az osztályok, a csatolófelületek, a struct, az enum és a 
még különlegesebb delegate és függvénymutatók, a C, a C---k 
és a Java keverékéből származnak. 

A korszerű objektumközpontú nyelvek legfontosabb jellemzőinek 
támogatására a Cs szintén rendelkezik a különböző elemszerkezetek 
— tulajdonságok, eljárások, attribútumok, események és leírás — 
lehetőségével. Ezzel nagymértékben leegyszerűsödik azoknak a 
fejlesztőknek a munkája, akik elemeket írnak és RAD-környezetbe 
akarják foglalni őket. 

Azoknak a programozóknak a számára, akik járatosak a Java vilá- 
gában, e kis C2-bevezetésben foglaltak semmilyen gondot nem 
fognak okozni. Bár az objektumközpontú programozásban gyakorlott 
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programozók érdeklődési területét ez a kis ismertető nem fedi le, a 
Kapcsolódó címek részben a Cs nyelv részletesebb leírásaihoz is 
találhatunk hivatkozásokat. 
Bevezetésképpen vessünk egy pillantást a jó öreg Hello World 
program Cs -ben írt változatára: 
4 xk 

A mello. cs forooram ködilistája 
51 


ISMÉT GáoSZ Ses 


ödlolíic elass Hal lakWo al 


( 
ödlolic static vond Main ) 
( 
ja (oj tést ölette átvesz z— I 0 Es RNS ő SzSz ea Ti 
// Console Írom the System 
// namespace 
Console  WeiteLiae( "Hello Worlal") : 
) 
5 
) 


folytatás a következő oldalon 


közösen előterjesztette a Common Language Infrastructure 
(CLI, általános nyelvi alap) nevű futásidejű környezet és egy 
újonnan kifejlesztett objektumközpontú nyelv, a Cs részletes 
leírását. 2001 második felétől a Ximian hivatalosan is elindította 
a Mono-projektet, azzal a céllal, hogy létrehozzák a javasolt 
szabványokon alapuló .NET fejlesztői környezet nyílt forrású 
megvalósítását. 2001 decemberében az ECMA (European 
Computer Manufacturing Association, Európai Számítógép- 
gyártók Szövetsége) hivatalosan is jóváhagyta a CLI és Cs 
leírásaira vonatkozó szabványokat. 


Áttekintés 

A CLI egy alaposztály-eljáráskönyvtárat és egy futtatókör- 
nyezetet jelöl ki, ennek feladata többek közt az azonnali (JIT, 
Just In Time) fordítást, memóriakezelést, kivételkezelést 
megvalósító szolgáltatások, valamint a befűzési- és biztonsági 
szolgáltatások nyújtása. A folyamat jobb szemléltetéséhez 
segítséget nyújt, ha összehasonlítjuk a forráskód fordításának 
hagyományos módszerével. 

A hagyományos folyamat szerint a forráskódot a fordítóprog- 
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folytatás az előző oldalról 


Minden programnak osztályokból kell felépülnie. 

A lista tetején egy megjegyzésrész látható. A Cs ugyanazt a meg- 
jegyzésformátumot használja, mint a Java vagy a C-- --. A több- 
soros magyarázatok használatához a kezdet jelzésére a /" jelet, a 
végén pedig a "/ jelet használjuk. Egysoros megjegyzések esetén 

a kettős perjel (//) szintén elfogadott. 

A megjegyzés alatt nem találunk fejállományt (header), mint a C 
vagy C-t - esetén. Láthatunk viszont egy utasítást, ami a Javából 
ismert import utasításra emlékeztet. A using kulcsszó a C-ben 
egy névtér megadására alkalmazható, ami lényegében egy osztály- 
gyűjtemény. Ebben az esetben a System az az osztálykönyvtár- 
névtér, amit megadunk. A Cs egy kis- és nagybetűket megkülön- 
böztető nyelv, így a Svstem nem azonos a system-mel. Szintén 

a Javához hasonló az a tulajdonsága, hogy az utasítások pontos- 
vesszővel zárulnak. 

Lefelé haladva a következő sor a legkülső osztály kezdete. A CS 
fájlonként több osztály megadását is megengedi, így a fájl nevének 
nem kell a legkülső osztály nevével megegyeznie, mint a Javában; 
ezzel szemben a fájl nevének .cs kiterjesztést kell kapnia. 

A Hello World osztály nyitó kapcsos zárójel utáni első sora 

a Main ( ) tagfüggvény. Minden programnak rendelkeznie kell 
Main () tagfüggvénnyel, ami a program belépési pontjának a szere- 
pét tölti be. A C-t és Java nyelvektől eltérően a Main ( ) nagy- 
betűvel kezdődik. A fő eljárás megadásában szerepel még a public 
static void kifejezés. A public beállítja az eljárás láthatóságát 
és elérhetőségét (lényegében bárki hozzáférhet). A static kulcsszó 
lehetővé teszi, hogy még azelőtt belépjünk az eljárásba, mielőtt egy 
Hello World típusú objektumot hoznánk létre. Végül a void 
kulcsszó azt adja meg, hogy az eljárás nem rendelkezik visszaadott 
értékkel. A C-ben a Main ( ) tagfüggvény vagy int típusú 
értékkel tér vissza, vagy semmilyen értéket nem ad vissza. 

A Main ( ) tagfüggvény belsejében az alábbi ciklus helyezkedik el: 
iraíeátázaál etánt tett USE See a 

// Console from the System namespace 
Console.WriteLine("Hello World") ; 
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ram (compliler) alakítja át a gépnek megfelelő utasításokká, 
amiket közvetlenül a processzor hajt végre. Egy x86-os soro- 
zatú processzor számára lefordított program egy PPC procesz- 
szoron hibát eredményez, ha a programot előtte a processzor- 
nak megfelelően nem fordítjuk újra. Mindez annyiban nehezíti 
egy program több eszközfelületre való megvalósítását, hogy 
minden egyes különböző változathoz rendelkeznünk kell a 
megfelelően fordított kóddal. 

A másik lehetőség, hogy egy olyan köztes futtatókörnyezet 
számára fordítjuk le a forráskódot, amelynek az utasításai 
függetlenek a háttérben működő eszköztől. A köztes utasí- 
tások ezután különböző módszerekkel hajthatók végre. Az 
egyik módszer, hogy egy értelmezőprogramot (interpreter) 
használunk. Az értelmezőprogram betölti az utasításokat, 
majd végrehajtja őket, mintha egy virtuális számítógép mű- 
ködne a háttérben. A második módszer szerint a köztes utasí- 
tások a gépnek megfelelő utasításokra való JII-fordítása futás- 
időben vagy a telepítéskor történik, s az utasítások ezután 
közvetlenül hajtódnak végre. Mivel a JII-fordítás a futtatófe- 
lületnek megfelelő utasításokat alkalmaz, a fordítás a célpro- 


A for ciklus formátumának a C, C-- -- vagy Java-programozók 
számára már ismerősnek kell lennie. A ciklus első része, az int 
x-0 egy x nevű egész típusú változót ad meg, és a 0 értéket adja 
neki. Ez a változó tölti be a ciklusszámláló szerepét. A ciklus 
középső része, az xc3 kifejezés az a logikai feltétel, ami eldönti, 
hogy mikor kell a ciklusnak befejeződnie. Esetünkben, ha az x 
értéke 3-nál nagyobb, a vizsgálat eredménye negatív, kilépünk a 
ciklusból. A ciklus utolsó része a frissítési szakasz. A C-- ---hoz 
hasonlóan a Cs is megengedi az utólagos (post) növelést és csök- 
kentést. Az x--- parancs az x—x-i-1 rövidítése. A frissítő szakasz 
minden ciklusvégrehajtás után lefut. A példában a ciklus 

3-szor hajtódik végre. 

ACsawhile, ado-while, a for és foreach típusú 
ciklusokat támogatja. 

A for ciklus belsejében a Console.WriteLine ( ) tagfügg- 
vény hívása található. A tagfüggvény hivatalos neve 

System. Console.WritelLine ( ) , de mivel kikötöttük, hogy 
a System névteret használjuk, a System kezdőrészt elhagyhatjuk. 
Hosszú programokban ezzel a fogással jelentős mennyiségű gépe- 
léstől kímélhetjük meg magunkat, de ha meggondolatlanul használ- 
juk, bonyolulttá válhat annak a meghatározása, hogy éppen melyik 
névteret használjuk. A Console.WriteLine ( ) tagfüggvény 

a kimeneti szöveget a rendszerkonzolra irányítja. A példaként vizs- 
gált kód végén lévő kapcsos zárójelek lezárják a ciklust, a tagfügg- 
vényt, majd az osztályt. 

A lista például egy Ahello.cs nevű szöveges fájlba menthető, majd 

a Mono CZ -fordítójával, az mcs-sel lefordítható. Az eredményként 
kapott hello.exe futtatható fájl az alábbi eredményt szolgáltatja: 

I 7 daténewton monolS mcs hello.cs 

Compilation succeeded 

I j daénewton monolS mono hello.exe 

Hello Woxrlal 

EENKKOKNY koráálkal 

ESA SKON orak] 

Természetesen a Cs sokkal többet érdemel annál, mint amit ebben 
a bevezetőben elmondhattunk róla. A Kapcsolódó címek részben 
néhány jó, a Cs nyelvet oktató segédanyagot találhatunk. 
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cesszornak megfelelően alakítható. A JII-fordító tovább 
növelheti a futtás sebességét, oly módon, hogy csak a felhasz- 
nálásra kerülő utasításokat fordítja le, majd a memóriában 
tárolja őket a későbbi hívások számára. 

A futtatókörnyezet használatának felületfüggetlenségéért 

a eredményt a futtatási sebesség terén kell köttetnünk. 

Az eszközfüggő kódra történő fordítás hagyományos módsze- 
réhez képest a végrehajtás lassabb. A sebességkülönbség 
mértéke függ az adott környezettől és a használt futtatási 
módszertől. Általában az értelmezőprogram használata 
igényli a legnagyobb futtatási időt. A JII-fordítást alkalmazó 
eljárás sebessége jóval közelebb áll a hagyományos fordítási 
módszeréhez, mivel mindkettő natív (az adott környezetnek 
megfelelő) utasításokat eredményez. A futásidejű többlet- 
munka azonban a sebességben mégis eredményez egy kis 
lemaradást. 

Most arra gondolhatunk: egy objektumközpontú nyelv, alap- 
eljáráskönyvtár, futtatókörnyezet — mintha csak a Javáról lenne 
szó. Ez igaz is — a CLI alkotóelemei nagyon hasonlítanak a 
Javában lévőkhöz, mégis van egy alapvető különbség. A Java 
futásidejű része kizárólag a Java nyelv futtatására lett kifej- 
lesztve. Igaz ugyan, hogy néhány más nyelvet is átalakítottak 
olyan módon, hogy a kimeneti kódja egyezzen a Javáéval, és 
ezáltal a JVM (Java Virtual Machine, azaz Java virtuális gép) 
számára futtatható legyen, de ez még mindig nem üti meg a 
CLI által biztosított nyelvfüggetlenség mértékét. Hiszen a CLI-t 
éppen arra tervezték, hogy számos programozási nyelv futtató- 
környezete lehessen. A CLI adattípus-rendszere az imperatív 
nyelvek (mint a C vagy a Pascal) és az objektumközpontú 
nyelvek támogatására egyaránt képes. 

A CLI nemcsak arra képes, hogy többféle nyelven írt progra- 
mot futtasson (nyelvfüggetlenség), hanem e nyelvek számára 
az egymás közti adatmegosztáshoz is alapot nyújt (nyelvek 
együttműködése), ideértve a többnyelvű kivételkezelést is. 

Az egyik nyelven létrehozott objektumnak a másikban is lehet- 
nek leszármazottai. Ha megvizsgáljuk a CLI alapvető össze- 
tevőit, megtudhatjuk, hogy milyen módszerekkel érhető el 

a nyelvi függetlenségnek ez a magas foka. 


A CTS 


A CLI lelke a közös típusrendszer, a CIS (Common lype 
System). A CIS egy osztott típusrendszert határoz meg, 

amely rögzíti az adatok megadásának, használatának és keze- 
lésének a szabályait. Ennek a szigorúan kötelező típusrend- 
szernek az alkalmazásával a CLI képes biztosítani a típusok 
épségét, és a nyelvek számára lehetővé teszi a másik nyelv 
adattípusainak kezelését. A nagyszámú különböző progra- 
mozási nyelv egyeztethetősége érdekében a CIS két fő adattí- 
pust biztosít, amelyek több altípussal, értékkel (értéktípussal) 
és objektummal (hivatkozástípussal) rendelkeznek. Az értékek 
az olyan egyszerű adattípusok számára vannak fenntartva, 
mint az egész és lebegőpontos értékek. Az objektumok a prog- 
ramozási nyelvek számára szükséges összetettebb egyedek 
leírására használatosak. 


A CLS 


A CLS (Common Language Specification, közös nyelvleíró) egy 
olyan keretrendszert ír le, amelyhez a fordítóprogramoknak a 
nyelvek közti adatcsere érdekében létrehozott programkönyv- 
tárak és bináris állományok előállításakor ragaszkodniuk kell. 

A CLS valójában a CIS részegysége, ami ésszerű adattípus- és 
szabályrendszert ad egy nyelv fordítóprogramja számára annak 


érdekében, hogy az így létrejövő lefordított kódot más nyelvek is 
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1. [ista Részlet egy visszafordított C$-programból 
a CIL utasításkészlet bemutatására 


/ /jöljaras 1l Köd 
.method public hidebysig specialname 


srtspecialname 
tiatsiszíncs Cdetavlt vond .ctor() ceirl 
s managed 
( 
[An O0520ec-mél kezdődő eljárás 
414 közméret 7 (Ü0x7) 
Simasasiareleütő 
TTMEKOO OO Saakelémasék0 
IL 0001: call instance void valuetype / 
el KccrlMoJESSzs Eme olog ect Ke Kor 
IL 00062 7TSE 
) rend cottmeehocreiétancésdetautts vedel 
/4 .atoIE( ) 


7/ Elljázéás 2 sox 
Smeleilaoeítotloltácses etette 
default void Main()  cil managed 
( 
// Az RVA O520£Tr4á-mél kezdődő eljárás 
METNSGYZTO OTA 
// Kódrészelet 11 
Miasss ee elütő 
ILL 00009 ILedetzx "EalLlo Woiziai" 


HT 00059 call void class / 


de) 


[corlib] System. Console: :WriteLine(string) 
IL. 000a: ret 


pe / vége la void MNMadn!) eljérásnak 


képesek legyenek használni, illetve kiegészíteni. Egy nyelv 
rendelkezhet arról, hogy milyen mértékben támogatja a CLS-t. 
Azok a nyelvek, amelyek bármely CL5S-típus használatát lehetővé 
teszik, az úgynevezett CLS-fogyasztók. Azok, amelyek képesek 
CLS-típusok létrehozására illetve kiterjesztésére, a CL5S-kiterjesz- 
tők. Végül azok a nyelvek, amelyek teljes mértékben magukban 
foglalják a CLS-t, egyszerre fogyasztók és kiterjesztők. 


A leíró adat és a CIL 
Amikor egy forrásfájlt egy CIL- (Common Intermediate 


Language, közös közvetítő nyelv) megfelelő fordítóprogram- 
mal fordítunk le, kimenetként egy hordozható futtatható 
bináris állomány (PE - portable executable) jön létre, amit néha 
assemblyként is emlegetnek, bár az assembly egynél több 
fájlból is állhat. A PE két fontos adatrészből tevődik össze. 

Az első a leíró adat, ami tartalmazza a használt típusok leírását, 
a CLI által az osztályok előkereséséhez és betöltéséhez használt 
adatokat, a memóriaelrendezést és egyéb, futásidőben szüksé- 
ges adatokat. A második rész a közös közvetítő nyelven írt CIL- 
kód. A CIL a közvetítőutasítások nyelvektől független gyűjte- 
ménye. Amikor lefordítunk egy nyelvet a CLI számára, ez a 
CIL-kód jön létre. A CIL megfelelő teljesítménnyel rendelkezik 
ahhoz, hogy rengeteg különböző programozási nyelvet kezel- 
hessen, és úgy tervezték, hogy nagy hatékonysággal lehessen 

a felületnek megfelelő natív utasításokra lefordítani. A CIL- 
utasítások egy kis része látható az 1. listán, a Hello World 
program C-ben írt változatában. 


2. lista A ljlib.cs fájl tartalma 
using System; 
namespace LlJlib ( 


public cLaélélkodáete 


1 
siuzisáketíjotloláke void SayHello () 
í 
(omS eNETN KS SET ék EN TENM Kó SM ÉTaól Se 
S Köjbiráme MINE 
) 
J 


3. [ista A hello.vb fájl tartalma 
ünyyeome SET 1b 


Module modmain 
Sub Main() 
GÜteut . Say He 1 NKGAW 
meltető 
End Module 


A VES 


A virtuális futtatórendszer (Virtual Execution System — VES) 
teremti meg a CLI-re írt programok számára a megfelelő fut- 
tatókörnyezetet. Végrehajtja a betöltést, a modulok egyesítését, 
vezérli a memóriát, megvalósítja a biztonsági szolgáltatások 

és kivételek kezelését, valamint megfelelő hátteret nyújt a 
CIL-utasítások végrehajtásához. 

A CLI memóriakezelő része tartalmaz egy szemétgyűjtőt 
(Garbage Collector — GC) is. Más futtatókörnyezetekkel szem- 
ben, a CLI megengedi, hogy a forráskódban engedélyezzük 
vagy tiltsuk a GC használatát. A GC által kezelt adatokat (lefog- 
lalás, felszabadítás) felügyelt (managed) adatoknak nevezzük, 
ha pedig a GC tiltva van, felügyelet nélküli adatokról beszé- 
lünk. A felügyelt kód (a CLI által végrehajtott forráskód) 
kezelhet felügyelt és felügyelet nélküli adatokat is. 


A Mono 


A Mono-projekt kettős célt szolgál. Az első, hogy az ECMA 
CLI- és Cs-szabványainak gyakorlati megvalósítását nyújtsa. 

A második, hogy mindezt a Microsoft .NE! fejlesztői felülettel 
együttműködő módon tegye. Mindkét résznek megvan a maga 
értéke, és különböző módon szolgálják a Linux javát. Ha pél- 
dául a .NEI-megfelelőség megszűnne, a Mono még akkor is 

a Linux egyik értékes fejlesztői keretrendszere lenne. 
Mindamellett a Mono azáltal, hogy a linuxos felületet .NE1- 
megfelelővé teszi, futtathatóvá teszi Linuxon a Windows alá 
fejlesztett programokat. A gondolatmenetet folytatva az is 
elmondható, hogy a fejlesztők számára immár rendelkezésre 
fog állni egy megszokott fejlesztői keretrendszer, amely a 
linuxos programok fejlesztésére történő átállás esetén csökkenti 
a tanulási kényszerből adódó korlátokat. 

A .NE1I-nek azok a fő részei, amelynek a kiadásán a Mono 
projekt éppen dolgozik, a Win Forms 
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(System.Windows.Forms), az ADO.NET és az ASRPNEI. A Win 
Forms tartalmaz minden szükséges eljárást, osztályt és ese- 
ményt a Microsoft Windows-rendszernek megfelelő grafikus 
programok kifejlesztéséhez. Mivel a natív Linux grafikus esz- 
közkészlettel szinte lehetetlen a Windows GUI API-hívásokat 
emulálni, a Mono a WinelLib (2 http:/www.winehg.com) 
segítségével adja a Windows-felületet. Ha már láttunk alkal- 
mazást a Wine alatt futni, akkor tudjuk, hogy a kinézete egyál- 
talán nem hasonlít a Linux asztali környezeteire. Ennek megol- 
dására a Wine-ban a Mono gondoskodik a témák támogatá- 
sáról, hogy ugyanazokat a leképező eljárásokat használja az 
elemkészletekhez, mint az asztal egyéb részeinél. 

Az ADONET tartalmazza a Mono számára a .NET adatelé- 
réssel kapcsolatos osztályait. Az ADO.NET többre képes 
egyszerű adatelérésnél: kapcsolat nélküli, méretezhető, 
XML-en alapuló adatelérési modellt nyújt bármely adatforrás- 
ból. Az írás idején körülbelül egy tucatnyi adatbázis működik 
a Mono ADO.NET adatszolgáltatójaként. A program fejlődé- 
séért, az újabb és újabb gyártó adatbázisának támogatásáért 
végzett munka folytatódik. 

A Monóban az ASPI.NE! támogatása két részre lett bontva: 

a webűrlapokra és webszolgáltatásokra. A webűrlapok alkotják 
a webalkalmazások felhasználói felületét. A Win Formshoz 
hasonlóan a webűrlapok is nyújtják a vezérlőeszközökhöz 

- gombokhoz, szövegdobozokhoz és egyszerűbb vezérlőele- 
mekből álló összetettebb elemekhez - tartozó tulajdonságokat, 
eljárásokat és eseményeket. Mindez lehetővé teszi, hogy a 
webes űrlap felülete RAD-eszköz (Rapid Application Develop- 
ment, gyors alkalmazásfejlesztő) segítségével készüljön, a fogd 
és vidd módszer alkalmazásával, a Gnome Glade programjá- 
hoz hasonlóan. Ezáltal a megjelenítés elválik a program logiká- 
jától, csökkentve a szükséges kódolás mennyiségét. A webes 
szolgáltatások egy SOAP alapú távoli eljáráshívás támogatását 
kínálják. Az olyan, mindenütt jelen lévő internetes protokollok 
használatával, mint az XML- és HTIP-szolgáltatások, az adatok 
és az eredmények hálózatos megosztását teszik lehetővé, még 
tűzfalakon keresztül is. Az ASRNET a CLI által támogatott 
bármelyik nyelven programozható. Ez azt is jelenti, hogy az 
ASRNET kódja lefordításra kerül, és nem értelmezőprogram 
segítségével fut, mint az ASP korábbi változatai vagy egyéb 
webes parancsnyelvek. Az ASRNET a Mono számára akár az 
XSP webkiszolgálón, akár az Apache 2 mod mono össze- 
tevőjével elérhető. 

A .NEI megvalósításában részt vevő Mono-osztálykönyvtá- 
rakon túl számos más programkönyvtár és eszköz is érdekes 
szolgáltatásokat kínál: 


e A GIKfZ, Otf és Wx.NET a népszerű linuxos grafikus 
eszközkészletekhez nyújt Cs-kapcsolatot. Ezekkel a Cs- 
burkolókkal minden, Monón futtatható nyelv ugyanazok- 
hoz a grafikus eszközökhöz nyer hozzáférést. 

e . Az OpenGLf, MonoGLo és CsGL a népszerű két- és 
háromdimenziós API OpenGL-hez ad kapcsolást. 

e . Az SDL.NET az SDL programkönyvtárhoz történő 
kötést biztosítja. 

e A Gstf Gstreamer multimédiakeretrendszer-kötés. 

e . Számos kommunikációs programkönyvtár, például 
a NET Jabber és a Gnutella. 

e NAnt fordítóeszköz (az Anthez hasonló eszköz). 


lermészetesen ez csak néhány példa, de elég ahhoz, hogy 
szemléltesse a Monónak azokat a képességeit, amelyek Linux 


af s 


vagy egyéb felületre történő fejlesztés esetén igénybe vehetők. 
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A Mono használata 

Az első lépés a Mono kipróbálásához a 

2 http:/www.go-mono.com címen a projekt honlapjának 

a meglátogatása, ahonnan letölthetjük a forrás tarcsomagjait, 
vagy a felületünknek megfelelő bináris állományokat. Pillanat- 
nyilag a Monónak Linuxon és Windowson futtatható átirata 
létezik, de folyamatban van a MacOS X, FreeBSD és más felüle- 
tekre történő átírás is. Számos Linux-változatra létezik bináris 
állomány, többek közt Debianra, Red Hatre, SuSE-ra és 
Mandrake-re. Ha a Ximian Red Carpetet használjuk, a neki 
megfelelő fájlokat a Mono Chanellen is fellelhetjük. A cikkhez a 
Mono 0.20-as változatát használtuk. Észrevehetjük majd, hogy a 
Mono programcsomagokon felül — amelyek a futásidejű, a Cs 
fordító- és osztálykönyvtárakat tartalmazzák — további cseme- 
géket is kapunk. Ezek között találjuk a Mono hibakereső prog- 
ramját, az XSP webkiszolgálót és a Monodoc leírásböngészőt. 
Amennyiben gondjaink akadnának a Mono telepítésével, 
forduljunk a honlapon elérhető leírásokhoz. 


A Mono jelenleg a következő összetevőkkel érkezik: 

e  Cs- és Basic-fordítóprogramok. 

e A VES, ami egy JII-fordítóból és a hozzá tartozó hulladék- 
gyűjtőből, a biztonsági rendszerből, az osztálybetöltő, 
ellenőrző és végrehajtó rendszerből áll. Egy értelmezőprog- 
ram szintén része ennek az összetevőnek. 

e . Egy CZ-ben írt osztálykönyvtár-gyűjtemény, amely a CLI- 
szabványban meghatározott osztályokat, a .NET FDL részét 
képező osztályokat és más Mono által használt osztályokat 
valósít meg. 

e . Különböző segédprogramok. 


Az mcs a Mono C4-fordítóprogramja. Érdekes programozói 
bravúr, hogy az mcs-t C-ben írták. A Mono 0.10 óta az mcs 
önmaga fordítására is képes. Ha érdekelnek bennünket az mcs 
parancssori lehetőségei, amelyek megegyeznek a Microsoft 
Cs/-fordítója által kínált kapcsolókkal, részletes súgóoldalak 
állnak rendelkezésünkre. 

A Visual Basic.NEI Monóban található megfelelőjének, a 
MonoBasicnek a fordítóprogramja az mbas. Bár a fejlesztése 
még nincs a Cs-fordítóéhoz hasonló állapotban, a Basickel való 
kísérletezgetéshez már megfelelő szolgáltatásokkal rendelkezik. 
A Mono két futtatókörnyezete a mono és a mint. A mono a 
VES CLI meghatározásaival egy JII-fordítónak megfelelő kör- 
nyezet. Ezzel ellentétben a mint egy értelmezőprogram, ami 

a mono számára könnyen hordozható megoldást jelent, de 
pillanatnyilag csak az x86-os felületet támogatja. A legjobb 
futási teljesítmény a mono használatával érhető el. 

A Monóval érkező segédprogramok közül figyelemre érdemes 
a monodis és a pedump. A monodis egy lefordított assembly 
visszafejtésére alkalmas, kimenete a megfelelő CIL-kód. Ezt 
használtuk az 1. listán látható CIL-kód megjelenítésére. Ha 
kíváncsiak vagyunk a CIL további részleteire, vagy bepillantást 
szeretnénk nyerni a hordozható futtatható kód előállításába, 
játszadozzunk el velük egy kicsit. 

Most, hogy már ismerjük a Mono összetevőit, itt az idő, hogy 
ki is próbáljuk őket. A Mono nyelvi párbeszédének próbájához 
C-ben egyetlen eljárással egy egyszerű osztályt írunk, majd 
egy MonoBasic-programból meghívjuk. 

A 2. lista mutatja a Ijlib.cs Cs-könyvtárat, a 3. listán pedig a 
hello.vb MonoBasic-program látható. Az első lépés a [jlib.cs 
programkönyvtárrá történő fordítása. A lefordított program- 
könyvtárak .dIl kiterjesztéssel rendelkeznek, a futtatható 
állományok kiterjesztése pedig .exe. 
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e Programkönyvtár fordításához az mcs -target : library 
kapcsolóját használjuk: 
[ ]-dagnewton]S mcs -target:library 1jlib.cs 
e Compilation succeeded 
Ennek eredménye a /jlib.dIl fájl, ami a Lj1lib névteret és 
Output osztályt tartalmazza. Most a hello.vb program 
fordítása következik. Ahhoz, hogy a fordításkor az éppen 
előállított /jlib.dIl fájl kerüljön felhasználásra, utasítanunk 
kell a MonoBasicet, hogy hivatkozásként ezt használja. 
Ezt a -r kapcsolóval tehetjük meg: 
[I ]-dagnewton]S mbas -r ./1jlib.dl1l hello.vb 
e  Compilation succeeded 
Az mbas kimenete a hello.exe fájl. Ezt a mono segítségével 
futtathatjuk is: 
[ ]j-dagnewton]S mono hello.exe 


Hello Linux Journal! 

És íme: két nyelv, a Cs és a MonoBasic egy futtatható állo- 
mányban egy időben működik. Bár ez egy végtelenül egyszerű 
példa, mégis jól mutatja a CLI nyelvfüggetlenségét és együtt- 
működési képességét, és jelzi a Monónak fejlesztőeszközként 
rendelkezésre álló széles körű lehetőségeit. 


Összegzés 

Bár a Mono még fejlesztés alatt ál, már így is a Linux program- 
fejlesztése elősegítésének nagy ígérete. Ha az utóbbi két évben 
mutatott fejlődését vesszük alapul, a Mono jövője nagyon 
izgalmasnak ígérkezik. 
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és azóta nem is tud szabadulni tőle. Ha nyelvtani 
vagy tárgyi hiba kapcsán keressük, akkor nem 
érhető el, de a dicséreteket és a jókívánságokat 
szívesen fogadja. 


A Cs összehasonlító áttekintése 
9 http://genamics.com/developer/csharp. comparative.htm 


A Cs a Java-fejlesztők szemszögéből 
2 http:/Avwvw.25hoursaday.com/CsharpvVsJava. html 


A Cs Stations Cs-oktató 
5 http:/Avww.csharp-station.com/Tlutorial.aspx 


Az ECMA CLI-szabványa 
2 http:/Avwvw.ecma-international.org/publications/standards/ 


ECMA-335.HTM 
Az ECMA Cső nyelvre vonatkozó szabvány 
2 http:/Avww.ecma-international.org/publications/standards/ 


ECMA-334.HTM 


A Mono projekt honlapja 3 http:/Avww.go-mono.com 


A Softsteel Cs-oktatója és , patchwork" könyve 
3 http://www.softsteel.co.uk/tutorials/cSharp/clndex.html 





Hálózatkezelés a Nagios rendszerrel 


A John Deere különféle alkatrészek és programok keverékére volt kénytelen 
kiterjeszteni a hálózati kezelőrendszert. A nap hőse a Nagios lett. 


mikor elkezdtem dolgozni a John Deere Agricultural 
AA Marketing Centerben, 12 állomásunk volt az Egyesült 

Államok és Kanada különböző pontjain. Ezek a telep- 
helyek eltérő felszereltséggel rendelkeztek: az összes feladatot 
régi kiszolgálókkal és asztali gépekkel oldották meg -— a tarto- 
mányszolgáltatástól egészen a nyomtatásig. Ez azonban nem 
igazán egyezett a központosított II-szervezetről alkotott elkép- 
zelésünkkel. Hogyan kezelhetnénk és figyelhetnénk meg a ki- 
szolgálókat és a WAN csatornákat ennyire változatos helyeken? 
Körülbelül két évvel ezelőtt úgy döntöttünk, hogy a felhasz- 
nálói adatokat hálózatunk központjából kivisszük a telephe- 
lyekre. A kérdés csak az volt, hogy miképpen tudjuk majd 
szemmel tartani az összes telephely különböző gyártóktól szár- 
mazó eszközeit? Hogy fogalmat alkothassunk a megfigyelendő 
eszközökről, bemutatunk közülük néhányat: minden fő helyen 
volt egy Maxtor 4100 hálózatra kötött tárolóeszköz (NAS) 
kiszolgáló, illetve egy Compag 1600, ami a nyomtatási és tarto- 
mányvezérlői feladatokat látta el. Néhány kisebb telephelyen 
helyi nyomtatókiszolgálóként Dell GX1 asztali gépeket hasz- 
náltunk. A központi állomáson egy Compag laskSmart N2400 
volt a legfőbb fájlkiszolgálónk. 
A változatos alkatrészek következtében egyetlen gyártó eszköz- 
vezérlő-készlete sem felelt meg az igényeinknek, az az ötlet 
pedig, hogy mindent más-más eszközzel figyeljünk meg, nem 
igazán tetszett. Így aztán gyártófüggetlen megfigyelőeszközök 
közül kellett választanunk. Az általunk talált megoldásokat meg- 
közelítőleg három nagy csoportba sorolhatjuk. A lista aljára azok 
a megoldások kerültek, amelyek nem igazán voltak képesek 
megfigyelni a folyamatosan növekvő számú kiszolgálót és asztali 
gépet. A legtöbb esetben kénytelenek lettünk volna a program- 
mal érkező eszközöknél maradni. Más programok az úgyneve- 
zett élvonalbeli eszközök közé tartoztak, ilyen például Hewlett- 
Packard OpenView rendszere. Ezt ugyan jól használhattuk volna 
ott, ahol szerettük volna, és képes lett volna megfigyelni is azt, 
amit akartunk, de az ára messze meghaladta lehetőségeinket. 





A NetSaint projekt 

Már éppen kezdtük elveszíteni a reményt, hogy találunk vala- 
mit, ami megfelel az igényeinknek, amikor belefutottam a Net- 
Saint projektbe. A NetSaint olyan megfigyelőrendszert ígért, ami 
megfelelt volna az igényeinknek, és képes lett volna megfigyelni 
azokat a dolgokat, amiket szerettünk volna, mégpedig egy nyílt 
keretrendszer segítségével, ami lehetővé tette, hogy saját bővít- 
ményeket (plugin) készítsünk. De a NetSaint segítségével nem- 
csak egyszerűen megfigyelhetjük a kiszolgálókat és a szolgálta- 
tásokat, de azt is lehetővé teszi, hogy a bemutatott irányvonalat 
követve munkáinkat előretekintőbb módon készítsük el. 
Minden nagyszerűen ment: a NetSaint megbízhatóan végezte 
munkáját a John Deere egyik kisebb irodájában. Ahogy telt- 
múlt az idő, a mezőgazdasági részleg belekezdett az I[1-részleg 
korszerűsítési programjába, azzal a célkitűzéssel, hogy a szak- 
értői területek színvonalát a teljes részlegben megemeljék. 
Ebben a projektben ismét felmerültek a megfigyelés régi bonyo- 
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Nagat dalmai. Mivel egy 


Service object 


központosítottabb II- 
szerkezet felé próbál- 
tunk meg el- 
mozdulni, a többi 
megfigyelőprogram 
valamennyi képessé- 
gével fel kellett vér- 
tezni magunkat. 10- 
vábbá minden egy- 
ség saját maga hoz- 
hatta meg az igényei- 
nek a legjobban meg- 
felelő ÍT-döntéseket. 
A kérdés tehát az 
volt: miként fogjuk 
össze a sokféle megfi- 
gyelőrendszert, és 
hogyan mozduljunk 
el egyetlen egységes 
megoldás irányába? 
Az új megfigyelőnek 
képesnek kell lennie 
kiszolgálók százait és 
szolgáltatások ezreit 
figyelemmel kísérni, 
miközben az egyes 
egységeknek lehetővé teszi, hogy a kialakult irányzatok adatait 
grafikonon ábrázolják. Ugyancsak nehézséget jelentett az 
eddigieknél is szórtabb megfigyelendő alkatrészkészlet, a 
Network Appliance-től kezdve a Sunon át a Dell-gépekig. 
lovábbra is voltak pénzügyi korlátaink, ez azt jelentette, hogy 
az OpenView-osztályú termékek kiestek a lehetőségek közül. 
Mivel termelési környezetünkben a NetSaintet futtattuk, úgy 
döntöttünk, nekilátunk és megpróbálunk NetSaint alapú meg- 
oldást keresni a mezőgazdasági részleg számára. Az első dolog, 
amit megtanultam, hogyha egy ideig nem követem a nyílt 
forrás közösségének a történéseit, akkor amikor visszatérek, 
igen sok változást tapasztalok. Esetünkben a NetSaint nem 
létezett többé; helyét átadta utódjának, a Nagiosnak 

(2 http:/www.nagios. org). 


1. kép A Nagat-szolgáltatások lapja 


Nagios — az utód 

ző lépcsőfokát jelenti. Némi szomorúsággal szemléltem, hogy a 
pingvin eltűnt a főoldalról, de lassan hozzászoktam a hiányához. 
A rendszer tanulmányozása után úgy döntöttünk, hogy a 
többszintű megoldást választjuk, s a megfigyelési projektünk- 
ben szóba kerülő minden egységnél külön Nagios-kiszolgálót 
helyezünk el. Elsősorban ezért döntöttünk így, hogy egyetlen 
kiszolgáló se terhelődjön túl, és a szükséges megfigyelési 
szintet folyamatosan fenntarthassuk. Ezt szem előtt tartva 
Moline-ban, Illinois államban telepítettük a fő megfigyelőgépet, 
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2. kép A NagMIN főlapja 


majd az első gyermekkiszolgálót a kansasi Lenexában, a 
mezőgazdasági részleg marketingosztályán helyeztük el. 


Telepítés 

A szülő- és a gyermekkiszolgálón ugyanaz a Nagios-telepítés 
futott. Mindkét gépre Red Hat 8-at telepítettünk, majd felpa- 
koltuk a Nagios rendszert. A rendszerrel érkező leírás csaknem 
teljes értékű, és szépen végigvezet bennünket a telepítés lépé- 
sein. A Nagios mellett minden kiszolgálóra egy Nagat nevű 
programot is feltelepítettünk (1. kép). 


A Nagat beállítóprogram 

A Nagat a Nagioshoz szánt webalapú beállítóprogram. Segítsé- 
gével mindössze egy weboldalon kell néhány mezőt kitöltöget- 
nünk, és a válaszaink alapján elkészül a beállításfájl. Így egyetlen 
terminálablak megnyitása nélkül a kevésbé tapasztaltak is be 
tudják állítani a Nagiost, illetve annak szolgáltatásait és gépeit. 

A Nagat használata során Red Hat 8-as telepítésünk alatt 
belefutottunk néhány nehézségbe. Megfelelőségi gondjaink 
elhárítására a PHP és az Apache egyik korábbi változatát kellett 
feltelepítenünk (PHP 4.1.2, Apache 1.3). Miután ezt megol- 
dottuk, hamar be tudtuk indítani a rendszert. A Nagat ugyan 
néhány hibát is magában rejtett, de könnyen kiküszöböltük 
őket. Az egyik hiba a service edit oldalon bukkan fel: a rendszer 
nem menti a kapcsolatcsoportot (contact). A javításhoz mind- 
össze annyit kell tennünk, hogy az alábbi sorokat a 39. sor 
case-szerkezetéhez illesztjük: 


Ssaveobject[ / contact groupsí] - 
daimplode(" "" , Ssaveobject ( "contact agroupsÍí] ) ; 


Ezek után kapcsolatcsoportunkba már gond nélkül kiment- 
hetjük a változásokat, a szolgáltatás frissítése közben. 


A kiszolgálók beállítása 

Miután mindent feltelepítettünk, elérkeztünk a projekt — véle- 
ményem szerint - legnehezebb részéhez: a kiszolgálók beállítá- 
sához. Végül maga a kiszolgálóbeállítás közel sem volt olyan 
nehéz feladat, mint kitalálni, hogy mit is várunk el rendsze- 
rünktől, majd végigjárni az odáig vezető utat. Az első döntés, 
amit meg kellett hoznunk - és amit éppen most vonunk 

vissza —, a Nagios fordítása beépített adatbázis-kezelés nélkül. 
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3. kép A NagMIN kapupásztázó 
felkutatja a megfigyelendő szolgáltatásokat 


Egy teljes évig meg is felelt az igényeinknek, de ahogy újabb 
egységeket építettünk be Nagios megfigyelő rendszerükbe, az 
általa nyújtott adatok elérése egyre fontosabbá vált. Többé már 
nem voltak elégségesek a Nagios saját kis grafikonjai. Magunk 
szerettük volna az adatokat megkapni és megjeleníteni, embe- 
rek és egységek szerint, ezt pedig nem éppen egyszerű meg- 
tenni az eredeti Nagios-telepítésünk által adott egyszerű szöve- 
ges állományokkal. 


A Nagios beállítása 

A következő lépést a főrendszer beállítása jelentette, ami a leg- 
több szempontból magától értetődő volt. Akad néhány dolog, 
amit érdemes egy kicsit jobban megnézegetni, ha a legtöbbet 
szeretnénk Nagios rendszerünkből kihozni. Az egyik ilyen 
képesség az intelligens ellenőrzés (smart check) módszere. 
Ahelyett, hogy rendszerünkön az összes ellenőrzést egyszerre 
futtatná (ez igen nagy processzorfelhasználással járna), a 
Nagios szétosztja az ellenőrzést, mondjuk ötperces időközökre, 
jelentősen mérsékelve ezáltal a CPU-felhasználást. A másik 
dolog, amit érdemes megnézni: a párhuzamosított szolgáltatás- 
ellenőrzés; ezáltal egy időben több ellenőrzést is futtathatunk, 
ami sokat segít, ha több processzorral rendelkezünk. 

A szülő- és a gyerekkiszolgáló beállítása szinte teljesen megegye- 
zik, akad azonban két lényeges különbség is. A gyermekkiszol- 
gálón alapértelmezés szerint a figyelmeztetéseket ki kell kap- 
csolni, illetve be kell állítani az aktív ellenőrzést (active check), 
míg a szülőkiszolgálón ennek éppen az ellenkezőjét kell végre- 
hajtanunk. Mindezt azért tesszük, hogy csökkentsük a terhelést 
a főkiszolgálón és az összes figyelmeztetést egyetlen gépen 
jelenítsük meg. (A kétféle kiszolgálóhoz használható beállítás- 
fájlok az 51. CD Magazin/NAGIOS könyvtárában találhatóak.) 
A következő lépés a Nagios által végrehajtandó parancsok 
megadása lesz. Kísérletet tettem arra, hogy a rendszert hasz- 
náló emberek eszébe véssem, hogy a Nagios: keretrendszer. 
Ez alatt azt értem, hogy ő maga semmilyen ellenőrzést nem 
hajt végre, ez a munka a Nagios által meghívható bővítmé- 
nyekre marad. És ez nagyon jó így, hiszen ezáltal könnyedén 
készíthetünk saját bővítményeket, mindaddig, amíg ragasz- 
kodunk a Nagios nyújtotta keretrendszerhez. Az általunk írt 
bővítmények segítségével olyan rendszereket is képesek 
leszünk megfigyelni, amiket az eredeti Nagios bővítményeivel 
nem tudtunk volna. Jelenleg képesek vagyunk megfigyelni 
például a NetApp fájlkezelőt (filer), és kiolvasni a lapszámlálót 
a HP nyomtatókból, valamint a Compag Insight Manager 
adatait be tudjuk építeni a Nagios rendszerbe. 

A Microsoft Windows-kiszolgálók megfigyelésének talán 
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4. kép Nagios-szolgáltatásrészletek 


legegyszerűbb (de nem az egyetlen) módja, ha kihasználjuk 
az NSClient képességeit. Az NSClient programot windowsos 
gépeinken szolgáltatásként futtassuk. Futtatásához nyissunk 
meg egy kaput a Windows-kiszolgálón -— biztonsági okokból 
érdemes jelszóval védeni a kapuelérést. Írásom születésekor 
még nem lehetett titkosítást használni a program és a Nagios 
kiszolgáló közötti kapcsolatban. A bővítmény lehetővé teszi, 
hogy elérjük a kiszolgáló memória- és lemezfoglaltságát, a 
processzorteljesítményt, illetve egyéb olyan adatokat, amiket 
Windows alatt egyébként a teljesítménykezelő (performance 
manager) eszköz segítségével érhetnénk el. 

Linux- és Unix-rendszereinkhez némileg eltérő módszert hasz- 
nálunk. A Nagios Service Check Acceptor (NSCA) nevű prog- 
ramot démonkért futtatjuk az inetd alól. A program haszná- 
latához a Nagios egy check nsca nevű bővítményt indít el, 
ami titkosított csatornát hoz létre a két számítógép között, majd 
a bővítmény segítségével lefuttatja a számítógép ellenőrzéséhez 
szükséges kódokat. A rendszer beállítása magától értetődő: 
válasszuk ki a két gép között használható titkosítási módszert, 
majd az ügyfélen adjuk meg a plugin parancsot. Ezt követően 
az adatokat máris átszipkázhatjuk Nagios rendszerünkre. 

Mint azt korábban említettem, jelenleg éppen azzal foglalko- 
zunk, hogy a Nagios által alapértelmezés szerint használt fáj- 
lokat háttéradatbázisba töltsük át. Ezt a módszert arra szeret- 
nénk használni, hogy jobb adatábrázolást érjünk el olyan esz- 
közök segítségével, mint például a Crystal Reports. A Nagios 
önmagában is támogat két adatbázis-kezelőt: a MySOL-t és 
PostgreSOL-t. A Nagios rendszerrel együtt néhány parancsfájlt 
kapunk, amelyek előállítják az adatbázist, és elkészítik Nagios 
rendszer működéséhez szükséges táblákat és mezőket. Mi a 
PostgreSOL mellett döntöttünk. Az adatbázis felállítása után 

a --with-nysal-xdáta vágy 4--with-ógsegi-xdata 
kapcsolók valamelyikével újra futtatnunk kell a beállítási pa- 
rancsfájlokat. Az xdata úgy állítja be a rendszert, hogy min- 
denhez adatbázisokat használjon. Jelenleg az egyetlen dolog, 
ami nem támogatja az adatbázisokat, maga a beállításfájl. 
Végül egy érdekességre szeretném felhívni a figyelmet: idén 
márciusban jött ki egy kiegészítés, mégpedig Nagios rendszer 
NagMIN elnevezésű Webmin bővítménye (2. kép). Ez a rend- 
szer nemcsak a Nagios webes beállítását teszi lehetővé (mint 

a Nagat), hanem néhány olyan dolgot is felkínál, amit eddig 
egyetlen eszköz sem. Először is lehetővé teszi a Nagios-beál- 
lításfájlok adatbázis-támogatását. Másodszor, ha a Nagios-tele- 
pítésünket akarjuk beállítani, igencsak jól jön kapuvizsgálat 
(port scan) képessége (3. kép). Még nem próbáltam ki e képes- 
ség minden lehetőségét, de állítása szerint hálózati felderítést 
végez, és a fellelt adatokat beilleszti a Nagios beállításfájljaiba, 
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megkímélve bennünket attól, hogy a rengeteg adatot mind 
nekünk kelljen felvennünk. A NagMIN a legtöbb rendszeren 
jól működik, de a különleges rendszereket valószínűleg min- 
denképpen kézzel kell felvennünk a rendszerbe. Amennyiben 
további tájékoztatásra lenne szükségünk a bővítménnyel 
kapcsolatban, látogassunk el a SourceForge.net honlapjára. 
Nagios kiszolgálónkat a szülő-gyermek viszony alapján állítot- 
tuk be. Ehhez némileg eltérő beállítások szükségesek, mintha 
egyszerű önálló rendszert készítenénk. Egyrészről a webfelü- 
letet csak a szülőkiszolgálóra telepítettük fel (4. kép). A gyer- 
mekkiszolgálók mindössze annyit tesznek, hogy ellenőrzési 
adataikat passzív ellenőrzési módszerrel egyszerűen áttöltik a 
szülőkiszolgálóra. Ennek kivitelezéséhez egy OCSP parancsot 
adtunk ki, ami lefuttatja az adatokat a Nagios szülőkiszolgálóra 
közvetítő parancsfájlt. Azáltal, hogy a parancsfájl futtatására az 
OCSP parancsot használjuk, minden egyes Nagios-ellenőrzési 
folyamat után le fog futni. Éppen ezért tulajdonképpen csak 

a gyermekkiszolgálóknak kell aktív ellenőrzéseket futtatniuk. 
Így a Nagios-szülőkiszolgálónak csak a webfelületet kell 
futtatnia, illetve hiba esetén elküldenie a jelentést. 

Most, hogy körülbelüli képet kaphattunk arról, hogyan állítot- 
tuk be a Nagiost, engedjék meg, hogy elmeséljem, milyen 
előnyökkel járt a használata. Ennek az évnek az elején vásá- 
roltunk egy lemplrax nevű digitális hőmérőt, ami együttmű- 
ködött a Nagiosszal. A hőmérőt fő számítógéptermünk hőmér- 
sékletének a megfigyelésére használtuk. Március eleje környé- 
kén aztán kiderült, milyen fontos is számunkra a Nagios. Egyik 
pénteken körülbelül déltájt üzenetet kaptam, miszerint a szá- 
mítógépterem hőmérséklete emelkedik. Miközben öltözköd- 
tem, a rendszer válságos helyzetről szóló üzeneteket kezdett 
nekem küldözgetni a számítógépszoba hőmérsékletével kap- 
csolatban. Mire beértem a munkahelyemre, a hőmérséklet 

80 fok körül volt, és egyre emelkedett. A Nagiosnak hála elég 
időm maradt, és fel tudtam hívni a légkondicionálásért felelős 
szakembereket, akik megjavították a berendezést, még mielőtt 
a számítógépeket komoly kár érte volna. Később kiderült, hogy 
a számítógépszoba A(C egységét vezérlő másik két rendszer 
képtelen volt kitárcsázni és riadóztatni a rendszert felügyelő 
szakembereket. Ha a Nagios nem figyelmeztetett volna 
bennünket a számítógépszobában előállt hibára, másnap reggel 
sokkal nagyobb bajjal találtam volna szemben magam. 
Egészében véve azt kell mondanom, hogy a Nagios kiváló 
hálózati megfigyelőeszköz. Keretrendszerről van szó, ami 
önmagában nem túl sok mindenre képes, de pontosan ez az, 
ami olyannyira nagyszerű eszközzé teszi. Mivel keretrendszer, 
csak azt végzi el, amire szükségünk van. Lévén nyílt, a bővít- 
ményeket tervezni hozzá éppolyan egyszerű, mint ellenőrzési 
adatainknak Nagios által is érthető formátummá alakítása. 

Így a bővítnényünk mindent felhasználhat, amit csak a Nagios 
nyújtani tud, és ez nem kevés. Végül a Nagios olyasvalami, 
amire mindenképpen vetnünk kell legalább egy pillantást 

— helyi telepítésünkön akár ki is próbálhatjuk. Kötve hiszem, 
hogy kiábrándulunk belőle. 


Linux dournal 2003. július, 111. szám 
] Aichard C. Harlan 
bh! (harlanrichardcécojohndeere.com) 


(1! Hálózati mérnök a lenexai John Deere 
Agricultural Marketing Centerben, Kansasban. 


2003. szeptember 41 


e El 


0 Kiskapu Kft. Minden Jog fenntartva 


0 Kiskapu Kft. Minden Jog fenntartva 


Hogyan indexeljunk? 
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Honlapunkon valószínűleg akad valamilyen keresőfelület — de mi a helyzet 
a súgóoldalak vagy a levelezőrendszer keresésével? 


zámtalan oka lehet annak, ha indexeket szeretnénk 
§ rendelni a dokumentumokhoz. Az egyik ilyen gyakran 

emlegetett ok a honlapok keresőfelülete, de ugyanígy 
elképzelhető, hogy valaki a levelezését vagy a műszaki doku- 
mentumait szeretné indexelni. Aki próbált már ilyen rendszert 
készíteni, az valószínűleg jól tudja, hogy egyáltalán nem olyan 
egyszerű dolog, mint amilyennek első látásra gondolnánk. 
Számos esemény jöhet közbe, ami megakadályozza a hatékony 
munkát. 
A vénséges vén és nélkülözhetetlen grep és társai igen haté- 
konyan keresnek szöveges adatokban. A grep, az egrep és 
rokonaik azonban nem tudnak bármit megadni nekünk. Nem 
keresnek több soron keresztül, nem tudnak rangsorolt keresési 
eredményt megjeleníteni, és lineáris keresési algoritmusuk 
nem igazán teszi alkalmassá őket a nagyobb dokumentumok- 
kal való munkára. 
A HIML sem lendít sokat a dolgon. Megjelenítés-központú 
képességei, egyedi nyelvezete, a formázási és entitástagok 
serege igencsak megnehezíti a helyes értelmezést. 
Az adattárolási skála másik végén az adatbázisokba szervezett 
adatok állnak. Mindenhol megtalálható példa erre az SOL 
adatbázis, amely viszonylag kifinomult keresési eszközökkel 
rendelkezik, de többnyire nem fut igazán gyorsan. Néhány 
adatbázismotor - kiemelten a MySOL 4 - a kérdést gyors és 
rendszerezett (ranked) kereséssel próbálja megoldani, viszont 
nem lehet a kívánt mértékben testreszabni. 
Ebből a cikkből megtudhatjuk, miképpen készíthetjük el a saját 
indexeinket Linux alatt a SWISH-E, a Perl és az XML segítségé- 
vel. A példákon keresztül bemutatjuk, hogyan használhatjuk 
a SWISH-E programot HIML-fájlok, PDF-fájlok és súgóoldalak 
indexének a felépítéséhez. 
A SWISH-E (Simple Web Indexing System for Humans — Enhan- 
ced) az 1994-ben Kevin Hughes készítette SWISS utódja. A SWISH 
1996-ban hibajavítás és új képességek hozzáadása céljából átke- 
rült az UC Berkeley könyvtárba. Az eredményt GPL alatt adták 
ki, és SWISH-E-re nevezték át. A fejlesztések Bill Moseley, a 
jelenlegi projektkarbantartó vezénylete mellett tovább folytatód- 
nak, Billt fejlesztők egész csoportja segít a munkájában. 
Mi a SkateboardDirectory.com-nál akkor akadtunk rá a 
SWISH-E-re, amikor indexelő eszközkészletet kerestünk. Rájöt- 
tünk, hogy egyedülálló képességekkel bír: a SWISH-E nemcsak 
gyors és erőteljes eszközkészletet kínál, amivel indexeket épít- 
hetünk, illetve kérdezhetünk le, de egyben kiválóan dokumen- 
tált, folyamatos fejlesztés és hibajavítás alatt áll, és Perl csatoló- 
felülettel is rendelkezik. Az is nagyon tetszett, hogy a csomag- 
felelős Moseley és a többi tapasztalt SWISH-E-felhasználó 
és -fejlesztő általában igen gyors és pontos választ ad, ha a 
SWISH-E-levelezőlistán kérdések vagy hibák merülnek fel. 


A SWISH-E telepítése 


Példánkat egy gyári Red Hat 7.3 munkaállomáson futtattuk, 
amire a Software Development csomagcsoportot telepítettük 
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fel. A példákat Red Hat 6.2-t futtató munkaállomáson, valamint 
Debian Woody alatt is kipróbáltuk. 

Jelenleg Red Hat alatt csak forrásból rakhatjuk fel a SWISH-E 
rendszert, továbbá felépítéséhez előzőleg a zlib és libxml2 
könyvtárakat is fel kell telepítenünk. Ha úgy tűnik, hogy 
valamelyiket fel kell raknunk, a terjesztésünk csomagjai között 
valószínűleg megtaláljuk. Példáinkban az xodf csomagot is 
használni fogjuk, így ezt is érdemes feltelepíteni, ha esetleg 
még nem tettük volna meg. Az általunk megjelölt Red Hat 7.3 
munkaállomás az összes SWISH-E rendszerhez szükséges 
valamennyi előtelepítési feltételt teljesíti. 

A következőkben bemutatjuk a SWISH-E 2.4 használatát, ami 
a fejlesztőcsapat szerint körülbelül a cikk megjelenésével egy 
időben lesz majd elérhető. A SWISH-E rendszert a következő 
parancsok sorozatával telepíthetjük (az x.x helyére az időszerű 
változatszám kerül): 


3 wget http://swish-e.org/Download/ 
swish-e-x.x.tar.gz 


£ 


ao 


tar zxf swish-e-x.x.tar.gz 
cd swish-e-x.x 

. /configure 

make 

make test 


a? ag a 


ao 


Ha a SWISH-E futtatható állományt, a C-könyvtárakat és 

a súgóoldalakat az alapértelmezett /usr/local könyvtárba 
szeretnénk helyezni, rendszergazdaként gépeljük be a make 
install parancsot. Így a SWISH-E végrehajtható állomány 
a /usr/local/bin könyvtárba kerül. Amennyiben ez a könyvtár 
még nincs a PATH útvonalunkban, két dolgot tehetünk: 

vagy módosítjuk a megfelelő ponttal kezdődő fájlt, hogy a 
/usr/local/bin könyvtárat is helyezze a PATH változóba, vagy 
teljes útvonalával együtt hívjuk meg a swish-e végrehajtható 
állományt: /usr/local/bin/swish-e. 

Most készítsük el és telepítsük a forrás Perl-könyvtárában 
található SWISH: : API Perl-modult. Később még szükségünk 
lesz rá, amikor a súgóoldalaink indexeihez használt Perl-ügy- 
felet készítjük el. A SWISH: : API modult a szokásos Perl 
modultelepítési folyamattal tehetjük fel: 


ao 


cd perl 

perl Makefile.PL 
make 

make test 


a? a 


ao 


Ezt követően a make insta11 parancsot rendszergazdaként 
begépelve telepíthetjük a SWISH-E Perl-modult. 

Miután a SWISH-E és a SWISH: : API Perl-modult teljesen 
feltelepítettük, a SWISH-E kipróbálásához a HIML-fájlok 
nyilvántartására készítsünk egy egyszerű indexet. Ebben a 
példában az Linux Documentation Project (LDP) HOGYAN- 


7. lista Az sman-index-prog.pl az indexeléshez súgóoldalakat alakít XML formátumúvá 


t!/usr/bin/perl -w 


tis ESSstrict; 
SEN a les : E1ritele 


mez (exelelséüesi les) za (0, get mán Tales ( ) ) ; 
warn scalar Efiles, " man pages to 
S delesze tet Vas 
IOIC  INNDZAÉS KKEL 1 L68) 1 
wecma vazocoessíimo Scatya umaless 1ascemt 3 205 
my (Shashref) - parse man(Stf); 
my Sxml - make xmil(Shashretf) ; 
my Ssizs z lemngeün Szal : 
print "Path-Name: SEWwn", 
ID (GETE Tree zzto E Es MNO Yen lát 
"Content-Length: SsizeMnAn", Sxml; 


sub get man files ( tHt angol kézikönyvoldalak 
IGE ESÉSE 


my Eéfiles; 
chomp(my Sman path - SENV(ÍMANPATH]) II] 
" mernoata 1]] " /usr/share/jmem ) ; 
adatta teli MS TGJ io 
my Sn —- SFile::Find: : name ; 
push éfiles, Sn 
if -f Sn €x Sn —- m!man/yzman."v.! 


ke Go LEE G zass meet Get E ő 
return Efiles; 


) 

gsuülo maka szml ( TT a tömo XMIL-változat kiírása 
my (Smetzas) zs E : 
OSZ Senna ÉS lta Koo atéátan ell VALE tan 
map í( "-S 5" . escape(Smetas-síS ]) 

EME a] 

keys $Smetas) ; 
MNZZNÉ S [ota ce (GIN zen MTNÉRVZ EST NK tn E UÁTNSER (0) ASSE Vért 
retüem Gori sorezallsszanláa/alLsyaj 5 

1 

sub escape ( ?t az átadott számokat módosítja! 
vetüzm "7" umaless detimed(sS 101): 
SE EAMTOK A) e IME Me [Ed 
Ge SEZTONG 
retürn S [0]; 

Í 

sub parse man í( t ez a lényeg 
my (Sfile) z E s: 
mi (dmeroage, szur comcemt) z (  , "  ); 
my (S-cutr sectiom, 31) z GwiNOSECTTION) ; 
open FH, "man Sfile ANT (Go ERNE kool I 


(e slot SNELUTSKEL MIBE el MENT Ae táartó tente és tölt bös 
ÁMSZZANNRNNA KESZ MTE ten S RSS PA MÉRT ESTLV 110) 
a TS IAN etette?) ENNE KÁL ERROL 0) 1 


jainak egy oldal/fejezet alapú változatának HIML-oldalait 
fogjuk indexelni, ami a —/HOWTO-htmlis/ könyvtárba kerül. 
A cikkben felhasznált LDP-dokumentumok a 

2 http:/www.tldp.org/docs.html oldalról származnak. 
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ENE ÁTLA NT 


while ( -FH35 ) 1 H kézikönyvoldalak 
H eszakaszolása 
SLimei z § az Slimel zzz /51y875S/ s 
manage ces líimeM E Se unless [61 S/; 
TERET 146 
SETS STT YVES ATS 
cmoamol mv Ssec z 51 ); 
SAE ettetek ák, ői (ebe ernietnés 
Seuz content za va 
Scuz sectiom - Ssac; § Új szakasz mév 


) 

Seuz content s § ünless /PYV875S/ s 
T 
Salscur section; .- Scaur contents 
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t megvizsgálandó "a NAME, HEAD: BOOT; 
CSE keg ea eTájinv át e 
close(FH) or die "Failed close on pipe 
— to mer" 
elm( ow(A AFIBAD A BEOOV)) sz (Slimsi, SlLíimeM) s 
TÖTT ESSEN E A Vg e yes 
ENTER ZOTT AAÁte mitet MEA [ADD TS rre MTA EAA TTL E TYNE LE SO (ETT ÉS 
torl(sort kevslsmn)) í ff először A AHEAD § 
xw6 A BFOOL 
TSZ ESTE ate S ete kégege 
t másolása 
IE (/ A TAHEAD] BFODTO SZIN ( 
t..Lőök €ör ené  SecLION d () a 
JE Az eV va 
some [ ől 


) elsít(Sk sz 
—gz ye (INOSBRTTFILONI ( NAME) §s7//) ( 
my e snamestt őv ISK; 


it (Snemestt 


zá! 


FÁNAK ZO ao KA KE Rt 
A NETES SEA 
) else ( $§ ez a regesz hibázhat. 
Smd [I- Snamestr 1] Sv; 
T 
) 
) 
last A TESTS MESZ S talent LÉK e E c NTNTTL HÁT EST ZAN zztrtLA TGLO ARA Hszt THAT HA EGT 


Sms z SÍ1l7? ff a €8s€ec-et a Data ből 
t vesszük ha nem található 
) 
Smart eler ss ae e gze tl 
—unaless sms 
my Smetas; 
dmetasí(aw(swishtitle sec desc page)) - 
(Smn, Sms, Smd, Smanpage) ; 
return ( vöőmetas ); Ht ref visszaadása 5- 
t kulcsos tömbnek. 


ATML indexelése a fájlrendszeren 

A SWISH-E alapú index létrehozásának első lépése a beállí- 
tásfájl elkészítése. Hozzunk létre egy —/indiíces nevű könyvtá- 
rat, majd lépjünk bele, és a következőket írjuk be egy 


2003. szeptember 49 


. TKKKSZÍTÉTŰTKÁNT 


0 Kiskapu Kft. Minden Jog fenntartva 


./howto-html.conf nevű állományba: 


t howto-html.conf 
IndexDir " . . /őHOWTO-html1s/ 


IndexOnly .html 


IndexFile ./howto-htmil . index 

Az IndexDir parancs adja meg azt a könyvtárat, ahol a SWISH- 
az indexelendő fájlokat keresi. Az IndexOnly utasítás jelzi, 
hogy csak a .htmil végződésű állományokat kell indexelni. Végül 
a létrehozandó index helyét a IndexFile utasítás adja meg. 


Az első indexünk 
A következő paranccsal készítsük el HIML-fájlindexünket: 


2 swish-e -c howto-html! .conf 


A -c kapcsoló adja meg, hogy melyik SWISH-E beállításfájlt 
kell felhasználni. Régebbi rendszereken az index elkészítése 
akár perceket is igénybe vett, egy mai gépen azonban egy perc 
alatt végezni kell. Az 1. ábra a HIML-fájlok SWISH-E alapú 
indexelésének folyamatát mutatja be a fájlrendszeren. 


Keresés az indexben 

Próbáljuk ki az új indexünket, és végezzünk el egy egyszerű 
keresést, ami megadja az NFS-kifejezéssel kapcsolatos HIML- 
fájlokat. A SWISH-E indexeket a swish-e végrehajtható 
állomány segítségével gyorsan és könnyen tesztelhetjük, ha 

az indexet a -f kapcsolóval adjuk meg, majd a keresett szöve- 
get a -w kapcsoló után írjuk. A SWISH-E indexek keresései kis- 
és nagybetűérzékenyek. Mivel igen sok oldalt (vagy találatot) 
várunk, ami tartalmazza az NES szót, a -m 3 kapcsolóval 
háromra korlátozzuk a keresések számát: 


2 swish-e -f howto-htmil.index -m 3 -w nfs 


Az előző sor a következőket adja vissza (rövidítve és újraformázva): 


1000 ../HOWTO-htmls/NFS-HOWIO/performance.html 
"Optimizing NFS Performance" 33288 

998 ../HOWTO-htmls/NFS-HOWTO/intro.htmil 
" mmtrodúction 10996 

993 ../HOWTO-htmls/NFS-HOWIO/ security.html 


"Security and NFS" 35968 

Nem rossz - ezek az oldalak egyértelműen az NFS-ről 
szólnak, és a kimenet is intuitív. Az első oszlop a SWISH-E 
által adott helyezés. A leginkább ide tartozó találatok mindig 
1000-es helyezést kapnak, míg a kevésbé ide tartozóak egyre 
kisebb rangot. A második oszlop a fájlnevet mutatja, a har- 
madik az oldal címét adja meg, míg a negyedik az indexelt 
adat bájtszámlálója. A SWISH-E egyik HIML-értelmező 
motorjának segítségével a HIML-tagokból minden egyes 
oldal címét meghatározza. 

A beépített SWISH-E értelmező motorok neve TXI, HIML és 
XML. Valamennyi értelmező a nevének megfelelő adattípus 
kezelésére képes. A SWISH-E jelenlegi változatai már képesek 
a libxmI2 könyvtár HIML2 és XML2 értelmező hátterét is 
használni. A beépített változatokkal szemben inkább az XML2 
és a HIML2 értelmező használatát javaslom, különösen igaz 
ez a HIMLZ2 esetében. Ez az oka annak, hogy a libxml2, bár 
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2. ábra letszőleges adatok indexelése külső programmal és SWISH-E-vel 


technikailag csak javasolt rész a SWISH-E létrehozásakor, 
majdhogynem előkövetelmények számít. 


A SWWISH-E keresési formátumának alapjai 

A SWISH-E teljes értékű szövegkereső nyelvvel rendelkezik, 
amelynek formátumában megtalálható az AND, OR, NOT logikai 
szerkezet és a zárójelezés. Valamennyi az elvárásoknak megfe- 
lelően működik. Például a következő kereséseknek logikus 
formátumú a szerkezete: 


3 swish-e -f howto-html.i1ndex -w nfs AND tcp 
3 swish-e -f howto-html.index -w nfs OR tcp 

3 swish-e -f howto-htmil.index -w "(gandalf OR 
frodo) OR (lord AND rings) 

A beállításfájl 


A SWISH-E beállításfájljai egyszerű szöveges állományok, 
amelyekben minden egyes sor parancs vagy megjegyzés lehet. 
Azokat a sorokat, amelyekben az első nem üres karakter a A 
(kettős kereszt), a SWISH-E megjegyzésként figyelmen kívül 
hagyja. Minden más nem üres sornak a következő formátu- 
múnak kell lennie: 


Utasítás kapcsoló lérték] 


Amennyiben üres karaktereket tartalmazó kapcsolót kell 
megadnunk, idézőjeleket használunk: 
Utasítás "kapcsoló üres karakterekkel!" 


Amennyiben a kapcsoló egyszeres idézőjelet (aposztrófot) 
tartalmaz, a kettős idézőjelet használjuk, és vice versa, például: 


"Fred/s Index Option" 
"Josh "joshr" Rabinowitz alkotása" 


Utasítás 
Utasítás 


(és ha a szöveg mindkét fajta idézőjelet tartalmazza, akkor 
sajnáljuk: — a ford.) 


A SWISH-E beállításfájljaiban tucatnyi parancsot adhatunk 
meg, a SWISH-E leírásában kimerítő listát találunk róluk. 


Az index 

Minden SWISH-E index egy fájlpárban tárolódik. Az egyik 

fájl neve az IndexFile utasítás alapján készül, a másik 

neve mindig indexname.prop lesz. Ha SWISH-E indexről 
beszélünk, mindig erre a fájlpárra gondolunk. 

Az indexek elég nagyra nőhetnek. Az iménti HIML-fájlindexelő 
példánkban használt index 11 MB-ot foglalt el — ez körülbelül 
az egynegyede az eredeti, beindexelt állományok méretének. 


PDF-állományok indexelése 

Egészen mostanáig csak a HIML-, XML- és szövegfájlok 
indexeléséről beszéltünk. Nézzünk meg egy haladóbb 

példát: indexeljünk be a Linux Documentation Project PDF- 
dokumentációit. 

Ahhoz, hogy a SWISH-E tetszőleges (PDF- vagy egyéb) fájlokat 
indexelhessen, az állományokat előbb szöveges fájlokká kell 
alakítani, lehetőleg HIML vagy XML alakúra, majd a SWISH-E 
segítségével indexelnünk kell az eredményt. 

A PDF-fájlokat tehát úgy indexelhetjük, ha a lemezen mind- 
egyiket átalakítjuk, majd indexeljük őket. Ehelyett azonban 
inkább megragadjuk az alkalmat, és egy rugalmasabb indexe- 
lési megoldást mutatunk be: a SWISH-E programozott elérési 
módszerét (2. ábra). 

A PDF-állományok indexelését a SWISH-E beállításfájl létre- 
hozásával kezdjük. Nevezzük el howto-pdf.conf-nak, majd a 
következő tartalommal töltsük fel: 


t howto-pdf.conf 


IndexDir . /howto-pdf-prog.pl 
t prog file to hand us XML 
t docs 
IndexFile . /nowto-pdaf . index 
t Index to create. 
UseStemming yes 
MetaNames swishtitle swishdocpath 


Itt az IndexDir utasítás most azt jelenti, hogy a SWISH-E 

e külső program meghívásával kapja meg az indexelendő 
állományok adatait, és nem a könyvtárban található fáj- 
lokat használja. A UseStemming yes utasítás hatására a 
SWISH-E indexelés vagy keresés előtt kikeresi a szavak 
tövét. E nélkül a szolgáltatás nélkül a , runs" szó keresésekor 
a ,running" szót tartalmazó dokumentumokat nem találná 
meg. A szótőkereséssel a SWISH-E felismeri hogy a ,runs" 
és ,running" szavak töve azonos, és megtalálja a megfelelő 
dokumentumokat. 
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Beállításfájlunk utolsó, de nem kevéssé fontos bejegyzése a 
MetaNames utasítás. Ez a sor különleges képességgel ruházza 
fel az indexünket: lehetőségünk nyílik csak a címekben vagy 
fájlnevekben keresni. 

Írjuk meg az indexelendő PDF-fájlokról adatokat visszaadó 
külső programot! Hagyományosan a SWISH-E forrásával 
együtt egy pdf2xml.pm nevű példamodult is kapunk, ami 
az xpdf csomagot használva PDF-fájlokat alakít át XML 
formátumúvá, megjelölve őket a SWISH-E által használ- 
ható előtagokkal. Ezt a modult (a —/indices könyvtárba 
másolva) a howto-pdf-prog.pl nevű külső programunkban 
felhasználhatjuk: 


t!/usr/bin/perl -w 
use pdf2xm.l ; 


my Afiles - 
"find ../HOWTO-pdfs/ -name "r.pdf" 
5. print ; 
for (8fi1les) ( 
chomp ( ) ; 


my Sxml record ref - pdf2xml(S ); 
t Ez egy XML fájl 

t SWISH-E fejléc 

print SSxml record ref; 


) 


Miután a SWISH-E beállításfájllal és a fenti külső programmal 
felvérteztük magunkat, készítsük el az indexet: 


o 


3 swish-e -c howto-pdf.conf -S prog 


A -S prog kapcsoló mutatja meg a SWISH-E-nek, hogy az 
IndexDpir valójában egy program, ami az indexelendő 
adatokról ad vissza információkat. Amennyiben a -S prog 
kapcsolót elfelejtjük megadni, miközben külső programot 
használunk a SWISH-E-hez, magát a külső programot fogjuk 
indexelni és nem az általa leírt dokumentumokat. 

Miután a PDF-index elkészült, próbáljunk ki egy keresést: 

3 swish-e -f howto-pdf.index -m 2 -w boot 
disk 


Ilyesféle eredményt kell kapnunk: 


1000 ../HOWTO-pdfs/Bootdisk-HOWTO.pdf 
"Bootdisk-HOWTO.pdf" 127194 
983 ../HOWTO-pdfs/Large-Disk-HOWTO.pdf 


"Large-Disk-HOWIO.pdf" 85280 

A MetaNames utasítás alkalmazása folytán címek és a PDF- 
fájlok útvonala szerint is kereshetünk: 

3 swish-e -f howto-pdf.index -w 
swishtitle-apache 


3 swish-e -f howto-pdf.index -w 
swishdocpath-1linux 


A keresések minden kombinációja támogatott, például: 
3 swish-e -f howto-pdf.index -w 
wall) 

OR (swishdocpath-linux OR 
swishtitle-kernel) " 


"(larry and 
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Az előbbi példában azért szükséges idézőjeleket használnunk, 
hogy a zárójeleket megóvjuk a héjprogram értelmezésétől. 


súgóoldalak indexelése 

Utolsó példánkban megmutatjuk, hogyan készíthetünk súgó- 
oldalainkhoz hasznos és hatékony indexeket, és miként hasz- 
nálhatjuk a SWISH: : API Perl-modult az index-keresőfelület 
kialakításához. Ahogy eddig is, a munkát a beállításfájl 
elkészítésével kezdjük: 


t sman-index.conf 
IndexFile ./sman. index 

t elkészítendő index. 
IndexDir  ./sman-index-prog.pl 
IndexComments no 

t a megjegyzések szövegeit nem indexeljük 
UseStemming ves 
MetaNames swishtitle desc sec 
PropertyNames desc sec 


A legtöbb utasítás jelentését már korábban bemutattuk, most 
azonban néhány új MetaNames nevet is megadtunk, illetve 
egy új, PropertyNames nevű parancsot vezettünk be. 
Dióhéjban összefoglalva: a MetaNames határozza meg, 

hogy mi alapján keressen a SWISH-E. Az alapértelmezett 
MetaName a swishdefault, azaz ha a lekérdezésben nem 
adunk meg MetaName kapcsolót, akkor ez alapján fog 
keresni. A PropertyNames a visszaadott találatok leírására 
használható mező. 

A SWISH-E által visszaadott eredmény általában az Auto 
Properties (önműködő tulajdonságok parancs) szerint 
jelenik meg, ilyen a swishtitle, swishdesc, swishrank 
és a swishdocpath. A beállításunkban olvasható MetaNames 
utasítás azt jelenti, hogy egymástól függetlenül nemcsak a 
teljes dokumentum, hanem csak a címek, a leírás vagy a sza- 
kasz alapján is keresni szeretnénk. A PropertyNames sor 
mutatja meg, hogy minden egyes találat visszaadásakor a sec 
és desc tulajdonságot szeretnénk látni, vagyis az oldal sza- 
kaszát (sec) és rövid ismertetőjét (desc). 

A súgóoldalak XML formátumúvá alakítását és SWISH-E 
fejlécekké formázását az 1. listában látható módon végezzük 
(sman-index-prog.pl). 

Az 1. lista első ciklusa lesz a program fő váza. Itt pillantunk 
bele minden egyes súgóoldalba, szükség szerint értelmezzük, 
XML-é alakítjuk át, majd a SWISH-E igényeinek megfelelő 
fejlécekkel egészítjük ki: 


e Aget man file() a File: :Find függvényt használja 
a súgóoldalak könyvtáraiban, hogy megtalálja a feldol- 
gozandó súgófájlokat. 

e Amake xmil() és az escape ( ) együtt aparse man () 


által visszaadott hashref-ből készíti el az XML formátumot. 


e A parse man() végzi el a trükkös részt, kiemelve a szük- 
séges mezőket a súgóoldal forrásából. 


Most, hogy már megismertük a működését, használjuk is 
aprogramunkat: 


o 


23 swish-e -c sman-index.conf -S prog 
Miután ezzel megvagyunk, a swish-e -w kapcsolóját 


alkalmazva a korábbiakhoz hasonló módon kipróbálhatjuk 
a rendszert. 
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Végül nézzük meg, hogyan használhatunk SWISH: : API-t 
alkalmazó Perl-parancsfájlokat az imént elkészített indexhez, 
létrehozva ezzel a unixos apropos parancs egy fejlettebb 
változatát. A kódot a 2. listában (51. CD Magazin/5WISH-E 
könyvtárában) találjuk (sman). Lássuk röviden a szerkezetet: 
az 1-14. sor az alapértékeket állítja be és a parancssori kapcso- 
lókat értelmezi, a 15—23. sor kezeli a lekérdezést, illetve felüle- 
tes hibakezelést végez, végül a 24-39. sor jeleníti meg a lekér- 
dezés eredményét a SWISH: : API-n keresztül visszakapott 
Properties alapján. 

A Perl-ügyfél ilyen egyszerű. Próbáljunk meg súgóoldalainkból 
kikeresni egy témát: 


o 


ő ./émánm -in l boot disk 
Az alábbit kell visszakapnunk: 


ootparam (7) Introduction to boot time para... 


Ugyanakkor már a következőképpen is kereshetünk: 
53 ./sman sec-3 perl 


Ezáltal a keresést a 3. szakaszra korlátozzuk. lovábbá az sman 
program elfogadja a ——-max-tt parancssori kapcsolót, ami 
korlátozza a visszaadott találatok számát, a —-fi1le kapcsolót, 
ami megmutatja a keresett szavakat tartalmazó fájl nevét, és 

a -—-rank kapcsolót, ami az adott lekérdezésen belül kapott 
rangot mutatja meg: 


o 


6. ./ elmáit maxi --file --rank Boot 
A fenti parancs a következő eredményt adja: 


1000 lilo.conf (5) configuration file for 1i1lo 
Z/üsv/manzmanszililo cent, 5 


Figyeljük meg, hogy a rang az első, míg a forrásfájl az utolsó 
oszlopba kerül. 

A sman csomag fejlettebb változatát a 

2 http://joshr.com/src/smar/ címen érhetjük el. 


Osszefoglalás 

A SWISH-E rendszerének van két említésre érdemes árnyoldala 
is. Először is: csak a 8 bites ASCII adatokat kezeli. Másodszor: 

a SWISH-E indexből nem lehet elemeket törölni, a törléshez a 
teljes indexet újra létre kell hozni. A mérleg másik serpenyő- 
jében a SWISH-E számos olyan képességét találjuk, amit itt még 
csak megemlíteni sem tudtunk. A részleteket a SWISH-E 
honlapján, a 3 http:/www.swish-e.org címen találhatjuk meg. 


A cikkhez tartozó listák megtalálhatóak az 51. CD Magazin/ 
SWISH-E könyvtárában. 
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Josh Rabinowitz 

13 éve a programipar veteránja, aki tudását 

a NASA Ames-i kutatóközpontjában, illetve 

a CNEI.com-nál és egyéb webcégeknél 
csiszolgatta. Jelenleg független tanácsadó és 
a SkateboardDirectory.com kiadója. 





inverz kinematika a Blenderben 


Ismét eljött az ideje, hogy új tudásra tegyünk szert 
a Blender képességeinek megismerése során. 





emélem, kedves olvasóim, 
R mára már sikerült kellőképpen 

elmélyedni a korábban elsajá- 
tított ismeretekben, így a továbbiakban 
nem fog gondot okozni a program 
használata és különféle lehetőségeinek 
megértése. 
Ebben a hónapban azt szeretném rövi- 
den bemutatni, hogy karaktereinkhez 
hogyan készíthetünk inverz kinematika 
által mozgatott csontvázakat. Kezdetben 
egy egyszerű módszert szeretnék aján- 
lani a karaktermodellezés mikéntjével 
kapcsolatban. Egy csomó felesleges 
munkától kímélhetjük meg magunkat, 
ha betartjuk az alábbi sorrendet. 


A terv 

Először gondoljuk át, hogyan fog kinéz- 
ni a karakter, majd készítsünk minél 
részletesebb rajzokat róla. Ezeket később 
a modellezés során is felhasználhatjuk, 
hiszen a pontos modellezéshez elenged- 
hetetlenek. lermészetesen a mintázato- 
kat is könnyebben elkészíthetjük, ha 
egyszer már megrajzoltuk őket. Készít- 
sünk elöl-, oldal- és felülnézeti képeket, 
és a modellezőprogramban használjuk 
őket háttérképként és segítségként egy- 
aránt. A rajzok mellett legalább elkép- 
zelés szintjén szükségesnek tartom a 
háromszögek elhelyezkedésének átgon- 
dolását is. A következő lépésben tervez- 
zük meg, hogy milyen mozgásokat 

kell végeznie a figurának, és gondoljuk 
át a csontváz szerkezetét. Modellezés 
során a csontváz létrehozásával kezdjük, 
erre könnyebben felépíthetjük majd a 
figurát. Ezután következhet a modell 
elkészítése, majd a mintázatokat képol- 
vasóval és rajzprogrammal elkészítjük 
és finomítjuk. Utolsó előtti lépésként 

a modell mintázatának elhelyezése és 
pontosítása következzen, ezek után a 
mozdulatsorokat modellezzük a csont- 
váz mozgatásával. 

A fentiek betartásával könnyebben és 
rövidebb idő alatt tudunk majd mozgó 
figurákat modellezni, és szemet gyö- 
nyörködtető animációk vagy játékok 
készítéséhez használhatjuk fel őket. 
Most tehát ismerkedjünk meg az inverz 
kinematika létrehozásának lehetőségeivel! 
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Mozgás! 

Mint azt a korábbi részekben emlí- 
tettem, az inverz kinematika teszi lehe- 
tővé, hogy amikor valamilyen tárgyat 
mozgatunk, annak mozgása ne csak 
önmagában létező legyen, hanem 

a mozgás során az összekapcsolt tár- 
gyak egymásra hatása is megjelenjen. 
Egyszerű példaként az emberi kar moz- 
gása hozható fel, hiszen nem helyezhe- 
tem tetszőleges helyre a kézfejemet 
anélkül, hogy az alkar és a felkar is ne 
mozogna, és a kézfejhez kapcsolódó 
testrészek hosszúsága is korlátozza 

a kézfej mozgását. 

Úgy gondolom, ennyi bevezető után 
elkezdhetjük a gyakorlati munkát. Egy 
három ízből álló csontváz mozgását 
tanuljuk meg, ennek alapján a későb- 
biekben bonyolultabb vázakat is képe- 
sek leszünk mozgásra bírni. Oldalnézet- 
ben hozzunk létre egy három részből 
álló vázat a Főmentü/Add/Armature 
menüpontok kiválasztásával. Az egyes 
részeket nevezzük el fentről lefelé, a 
,Comb", ,Lábszár" és a , Lábfej" megne- 
vezéseket használva. Ehhez ki kell je- 
lölni a vázat, majd a TAB billentyű alkal- 
mazása után minden részt is az A bil- 
lentyűvel. Ekkor az F9 billentyűvel vált- 
sunk át a szerkesztőnézetbe, majd a 
nézet közepe felé látható , Bone" neve- 
ket változtassuk a fentieknek megfele- 
lőkre. Ezt csupán azért kellett megtenni, 
hogy a kedves olvasók hozzászokjanak 
a nevek használatához, hiszen amikor 
emberi csontvázat készítünk, köny- 
nyebben eligazodunk az ismerős nevek 
között, mint a számozott csontok 
között. lermészetesen a továbbiak 
megértése is könnyebben megy majd, 
ha például a leírás szerinti , Comb" 
megtalálásához nem kell minden eset- 
ben a szerkesztőnézetben keresgélni 

a csontok között. Miután elneveztük 

a csontokat, még egy két részból álló 
vázat kell létrehozni, amivel majd befo- 
lyásolhatjuk a mozgást. A szerkesztő- 
módban jelöljük ki a boka helyén lévő 
kör alakú csatlakozási pontot, majd a 
SHIFT-S billentyű hatására megjelenő 
menüből válasszuk a legalsó pontot. 
Így a térbeli kurzor pontosan a boka 
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helyére kerül. Szüntessük meg a kije- 
lölést, és az előbbi módon hozzunk létre 
egy új vázat. Mivel ennek az irányító 
váznak a részei nem csatlakoznak 
egymáshoz, újra szüntessük meg a 
kijelölést, és a fő vázon a lábfej végét 
kijelölve helyezzük el ide a kurzort 

(a SHIFT-S ismételt alkalmazásával). 
Szüntessük meg ismét a kijelölést, majd 
a vezérlő vázat kijelölve váltsunk szer- 
kesztőmódba. Itt következik a másik 
vezérlőrész létrehozása, vagyis a főme- 
nüből ismételten válasszuk ki az Arma- 
ture pontot. Ezek után a létrehozott 
csontoknak adjuk a , Sarok", illetve a 

, LábfejControl" nevet. Amennyiben 
mindent jól csináltunk, a továbbiakban 
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az első képen látható szerkezettel dol- 
gozhatunk. Megjegyzem, hogy a képen 
a mozgatandó váz van kijelölve, tehát 
az látható rózsaszínnel jelölve, a fenti 
lépések után azonban a Blenderben 
még nem látható a , LábfejControl" -t és 
a , Sarok" vastagabbik végét összekötő 
szaggatott vonal. Ez a vonal jelenti azt, 
hogy a két csont alárendelt viszonyban 
áll egymással, és a helyes mozgáshoz 
ezt is be kell állítani. Ezt a két csontot 

a szerkesztőmódban kijelölve a szer- 
kesztő nézetben megjelenik a csontok 
neve és az is, hogy milyen viszonyban 
vannak egymással. Ezt az információt 

a név mellett látható child of mező tar- 
talmazza, és nekünk kell most beállítani 
a ,Sarok"-nak ezt a tulajdonságát. lehát 
a , Sarok" sorában válasszuk ki a legör- 
dülő listából a , LábfejControl" csontot. 
Így a létrehozott szerkezet már valóban 
megfelel az első képen láthatónak. 


Inverz kinematikai rendszer 

Ezek után nem sok teendőnk van, 
csupán a Blenderrel kell tudatni, hogy 
ezek a részek tulajdonképpen egy 
inverz kinematikai rendszert alkotnak. 
Itt lesz szükségünk az előző részben 
olvasottakra, nevezetesen a helyzetmód 
alkalmazására. Először azonban az eset- 
leges elfordulásokat és az egyéb változ- 
tatásokat mindkét vázrészen meg kell 
szüntetni. Ezt az ALTr-R billentyűkkel 
érhetjük el, de ne lepődjünk meg, ha a 
vázak helyzete megváltozik, hiszen így 
alaphelyzetbe kerülnek, ami megköny- 
nyíti további munkánkat. Végezzük el 
ezt a műveletet mindkét vázon. Ezután 
jelöljük ki a három részből álló csontvá- 
zat, majd a CTRL-IAB billentyűkkel vált- 


sunk helyzetmódba. Néhány ablakkezelő 


ezt a billentyűkombinációt az alkalma- 
zások közötti váltásra tartja fenn, ezért 
helyette használhatjuk a nézet alján 
lévő gombok közül azt, amelyiken egy 
sárga fejecske látható. Ez a rétegek 
megjelenítéséért felelős gombok után 

a tizenkettedik. 

Amikor ebben a módban dolgozunk, 

a kijelölt csontváz kék színnel jelenik 
meg. A sikeres váltás után jelöljük ki a 
,Lábfej"-et, és a szerkesztőnézet bekap- 
csolása mellett látható, láncszemeket 
ábrázoló gomb segítségével váltsunk át 
a korlátozásokat és kapcsolatokat meg- 
határozó nézetre. Itt kell majd meg- 
adnunk, hogy melyik rész milyen kap- 
csolatban van a többiekkel. Az Add 
gombbal hozzunk létre egy új elemet, 
és a megjelenő vezérlők között keressük 
meg a Constraint type mezőt. Ez a kis 
x mellett található, és a listából ki kell 
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választanunk az IK Solver típust. 
Ennek hatására a típus alatt megjelenik 
egy OB szerkesztőmező, ahová be kell 
írni azt az objektumot, amellyel vezé- 
relni fogjuk a csontváz mozgását. Ebben 
az esetben nem neveztük át a két csont- 
ból álló vázat, így annak neve Arma- 
ture.001 maradt. Ezt kell a billentyűzet 
segítségével beírnunk az OB mezőbe. 
Ahogyan ezzel elkészültünk, megjelenik 
egy újabb szerkesztőmező, ahová a 
,Sarok" nevet kell beírni, hiszen ez a 
csont fogja vezérelni a teljes csontváz 
mozgását. Ezzel készen is vagyunk. 
Szüntessük meg a kijelölést, és a két 
részből álló váz mozgatásával máris egy 
működő rendszert láthatunk. 
Felmerülhet a kérdés, hogy ha ez ilyen 
egyszerű, akkor miért volt szükség a 

, LábfejControl" vázrész létrehozására. 
Nos, ezzel tudjuk majd a lábfej elfor- 
dulását szabályozni. Ennek eléréséhez 
azonban újra az előbbi korlátozó ténye- 
zőkhöz kell újakat adnunk. Jelöljük ki 
megint a fő vázat, majd helyzetmódba 
váltva a , Lábfej"-et is. Adjunk újabb 
korlátozó elemet az Add gombbal a váz- 
részhez, ezúttal azonban az alapértel- 
mezett Irack to típusú elemen a típust 
hagyjuk változatlanul. Az OB ismét az 
Armature.001 legyen, azonban az elem- 
hez tartozó csontként most a , Lábfej- 
Contol"-t kell beállítani. Az eredménye- 
ket megszemlélve látható, hogy a váz- 
rendszer a , Sarok" mozgatásával most 
megfelelően mozgatható, és a két rész- 
ből álló váz forgatásával a lábfej külön is 
képes forogni. Ha jobban megfigyeljük, 
akkor azt is észrevehetjük, hogy a 
mozgás nem tökéletes. Néhány helyzet- 
ben az egész láb kifordul, nem tudjuk 
például vízszintesen előrenyújtani. Ezen 
további korlátozó elemek létrehozásával 
könnyen segíthetünk. Szintén a fő 
vázon kell dolgoznunk, de első lépésben 
a Comb" -ot jelöljük ki. Adjunk egy 
újabb Track to elemet a vázrészhez, en- 
nek célját állítsuk az Armature.001 ob- 
jektum , LábfejControl" csontjára. A kö- 
vetkező lépés legyen a , Lábszár" elem- 
hez egy újabb korlátozó tényező hozzá- 
adása, célja szintén az Armature.001 
váz, de itt a követendő csont a , Sarok" 
lesz. Ezeket a lépéseket megtéve már 
minden pozícióban helyesen fog állni 





2. kép Kiindulás a játékhoz 





3. kép A kezdősebesség beállítása 


a háromízű váz. Itt kell megemlítenem, 
hogy a Irack to elemet más esetekben 

is eredményesen használhatjuk, például 
amikor a kamerának követnie kell egy 
objektum mozgását - alkalmazzuk 
bátran ezt az elemet. A Copy Location 
és a Copy Rotation elemek használata 
magától értetődő, így ezekkel most nem 
foglalkozom részletesen. 


Játék megalkotása 

Úgy gondolom, hogy mostanra már 
eleget tudunk a Blenderről ahhoz, hogy 
elkészítsük első egyszerű játékunkat. 

A jobb érthetőségért célszerű tisztáz- 
nunk néhány alapvető dolgot. 

A Blenderben a játékmotorban négyféle 
elemtípust találhatunk. Az egyik a tulaj- 
donság, amely egy-egy tárgyunk sajátja, 
és típusa a különféle programozási 
nyelvekben megszokottaknak megfele- 
lően lehet egész, valós, logikai és 
szöveg. Itt lehetőségünk nyílik egy 
úgynevezett Timer típusú tulajdonság 
használatára is, ennek kezdőértéket 
adhatunk, majd az értéke önműködően 
növekszik. A második típus az érzékelő, 
amellyel különféle események bekö- 
vetkezésekor indíthatunk el valamilyen 
folyamatot. Ennek típusa is többféle 
lehet, itt azonban csak a Keyboard, a 
Always és a Collision típusú érzékelőket 
fogjuk használni -— ezekkel részletesen 
foglalkozom. A Keyboard alkalmas 
különféle billentyűzettől érkező ese- 
mények figyelésére, megadható, hogy 
melyik billentyű lenyomására legyen 
érzékeny, milyen módosítóbillentyűkkel 
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4. kép A pattogás logikája 


együtt figyelje a billentyű lenyomását, 
és hogy amikor az adott billentyűt 
lenyomtuk, akkor a tárgyunk milyen 
tulajdonsága változzon meg. Az Always 
típusa érzékelő, tehát a megadott gya- 
korisággal jelzéseket továbbít a kime- 
netén. A Collision alkalmas arra, hogy 
egy megadott tulajdonsággal vagy 
anyagtípussal rendelkező tárggyal való 
ütközést érzékeljen. 

Az eddigieket próbáljuk megvalósítani 

a gyakorlatban is. Kiindulásként 
hozzunk létre egy gömböt, egy síklapot 
és egy kockát, majd ezeket helyezzük 

el a 2. képen látható elrendezésben. 

A játék célja az lesz, hogy egy akadály- 
pályán keresztül kijussunk a gömbbel 

a kijáraton. A kijárat a pálya másik 
végén lesz. 

Kezdetben adjunk anyagot a síklapnak, 
és ezt az anyagot nevezzük , Floor"-nak. 
Ezután a kockát kijelölve az F8 billen- 
tyűvel kapcsoljunk játéknézetbe. Itt állít- 
hatjuk be a játék működését meghatá- 
rozó tulajdonságokat, érzékelőket és 
egyéb, a működést befolyásoló eleme- 
ket, amelyekről a későbbiekben bőveb- 
ben szólok. Most a kocka kijelölése után 
kapcsoljuk be a nézet bal felső sarkánál 
található Actor kapcsolót, ezzel tudat- 
juk a Blenderrel, hogy ennek a tárgynak 
a tulajdonságait a játék futtatása során 
figyelembe kell vennie. Kapcsoljuk még 
be a megjelenő Dynamic kapcsolót is. 
Ezzel a fizikai törvények is hatni fognak 
a tárgyra, ami most elsősorban a gravi- 
táció miatt lesz fontos, hiszen ez lesz 
majd az egyik akadály, a labdának ami a 
pálya síkja felett pattogni fog. Ha most a 
P billentyűvel elindítjuk a játékot, akkor 
már láthatjuk is a mozgást, vagyis azt, 
hogy a tárgy elkezd lefelé esni, és ami- 
kor érintkezik a síklappal, akkor megáll. 
Ez már fél siker, célunk ugyanis a folya- 
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matos pattogás. Ezt úgy tudjuk megva- 
lósítani, hogy egy érzékelőt helyezünk 
a tárgyra, ami a síklap elérésekor jelez, 
és ekkor a kockának új irányt adunk. 
lehát a következő lépésben a nézet kö- 
zepe felé a Sensors felirat alatt találunk 
egy gombot, amivel új érzékelőt adha- 
tunk a tárgyhoz. Az Add gomb alkalma- 
zásával hozzunk létre egy új elemet, 
ennek típusát pedig a megjelenő legör- 
dülő listából kiválasztva állítsuk 
Collision-ra. Itt található még egy M/P 
kapcsoló is, amivel választhatunk, hogy 
az adott anyaggal vagy tulajdonsággal 
rendelkező tárggyal való ütközéskor 
jelezzen-e meg az érzékelő. Ezt a kap- 
csolót is kapcsoljuk be, majd a mellette 
lévő mezőbe írjuk be a , Floor" szócskát. 
Ezzel elértük, hogy az érzékelő olyan 
tárgyakkal való ütközéskor jelezzen, 
amiknek az anyaga , Floor" nevű. Ilyen 
tárgy jelenleg egy szerepel a jelenetben, 
a síklap. Az érzékelő beállítása után 
már csak azt kell megadnuk, hogy mi 
történjen a jelzés hatására. A nézet jobb 
oldalán találhatók az események ered- 
ményeként létrejövő hatások. Itt is alkal- 
mazzuk az Add-ot, és az alapértelmezett 
hatás megjelenése után állítsuk be 
annak jellemzőuit. Amikor a kocka eléri 
a síklapot, arra van szükség, hogy újra 
felfelé induljon el. Úgy biztosítunk 
számára kezdősebességet, hogy a linvV 
érték Z irányú összetevőjének pozitív 
értéket adunk meg. Ez látható a 3. képen, 
a szükséges változtatás pirossal van 
jelölve. Én a példámban 8-as kezdő- 
sebességet határoztam meg, ami arra 
elegendő, hogy a kocka addig a magas- 
ságig pattanjon fel, ahonnan elindult. 


Rugalmasság 
Ideje, hogy egy, az eddigiek során kissé 
elhanyagolt anyagtulajdonsággal is 





foglalkozzam, a dinamikai tulajdonsá- 
gokkal. Az anyagszerkesztőben a színek 
meghatározása mellett találhatunk egy 
Dyn feliratú gombot, ezt bekapcsolva 
megadhatjuk az adott anyag rugalmas- 
ságát, tapadási együtthatóját és azt, 
hogy mennyi perdületet szerezzen az 
ütközés után. Ezek használatához azon- 
ban a játéknézetben is be kell állítani 

a Actor gomb alatt található Do Fh 
kapcsolót. 

Miután létrehoztuk az érzékelőket, 

és meghatároztuk, hogy a jelzés hatá- 
sára a tárgynak milyen tevékenységet 
kell végeznie, már csak a kettő közötti 
kapcsolatot kell meghatározni. Erre 
szolgálnak az érzékelők és a hatások 
közötti területen lévő vezérlők. Ezek- 
nek négy fajtája létezik, az AND és 
kapcsolatot jelent a kapcsolódó beme- 
neti jelzések között, az OR vagy kap- 
csolatot, míg a fennmaradó kettő 
működése általam jelenleg nem ismert. 
Szerencsére ez nem jelent gondot, 
hiszen a meglévő érzékelők és kapcso- 


latok elegendőek a játék elkészítéséhez. 


Válasszuk ki tehát a vagy kapcsolatot, 
és kössük össze a kimeneteket és 
bemeneteket. Ezek a sárga színű körök 
és a telt körök az egyes elemek mellett. 
Telt körrel jelölve láthatjuk a kime- 
neteket, amelyeket egyszerű kattin- 
tással és húzással az üres körrel jelölt 
bemenethez köthetünk. Végső lépés- 
ként kössük az értékelő kimenetét egy 
vagy kapcsolat bemenetéhez, majd 
ennek kimenetét a mozgatást megva- 
lósító hatás bemenetéhez. A 4. képen 
látható a helyesen kialakított vezér- 
lőrendszer. 

Ebben a részben eddig jutottunk, az 
összefoglaló táblázatban mindenki 
megtalálja a tanult billentyűkombiná- 
ciókat; a következő hónapban pedig a 
billentyűzetkezeléshez használható 
érzékelőket mutatom be majd, és foly- 
tatjuk a játék elkészítését. 


Fábián Zoltán 

z (dzoolkofreemaill.hu) 
Programozóként dolgozik. 
Szabadidejében szívesen 
kirándul, és szeret rajzolni, 
érdekli a 3D grafika. 
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A PHP5 újdonságai 





Újraírt Zend-motor, gyorsabb futás és továbbfejlesztett 
objektumkezelés — mindez év vége táján várható. 


yár van, mégsincs uborkaszezon a PHP háza táján. 

Június végén a nagyközönség elé tárták a PHP 5.0.0-s 

próbaváltozatát. A fejlesztés tehát eljutott első nyil- 
vános megjelenéséig (eddig csak CVS segítségével lehetett 
beszerezni), s már látni lehet az alagút végét. Számos jelentős 
változás lesz a 4-es vonalhoz képest, de semmi olyan, ami miatt 
meglévő PHP-programjainkat újra kellene írnunk, legalábbis 
nem nagyobb mértékben, mint az a 3-asról a 4-esre váltás során 
szükségessé vált. Nagyszámú olyan újdonság jön viszont az 
5-ös változattal, amit érdemes megismerni. 


Névterek 

Hasznos újdonság lesz a PHP életében a névterek bevezetése. 
Ez az apró kis adalék nagymértékben segítheti a nagyobb 
lélegzetű munkák szerkezetének a kialakítását, ráadásul külső 
osztálykönyvtárak és egyéb kódok anélkül könnyedén együtt 
használhatók, hogy bármiféle osztálynév-, állandó- (constans) 
vagy változónév-ütközés veszélye állna fenn. Márpedig ilyen 
jellegű galiba akár akkor is előfordulhat, ha csak egyszerűen 
többen dolgoznak ugyanannak a projektnek más-más részein, 
és ugyanazt a változónevet eltérő célból veszik használatba. 

A névterekkel némi logikai csoportosításra is lehetőségünk 
nyílik, az összetartozó osztályokat, állandókat egy térbe von- 
hatjuk. Névtereket létrehozni a namespace kulcsszó segítségé- 
vel tudunk. Lássunk egy egyszerű példát (lásd az 1. listát)! 

A példakód természetesen csak szemléltetésre alkalmas, de 

a lényeg látható. A namespace , kulcsszót" egy név követi, 
amellyel a továbbiakban hivatkozni tudunk rá. A terület kö- 
rülhatárolására hagyományosan a kapcsos zárójelek hivatottak. 
A névtér egy osztályhoz vagy függvényhez hasonlóan saját 
hatókörrel rendelkezik. Ez annyit tesz, hogy minden, a név- 
térben létrehozott függvény, változó, állandó a névtéren belül 


7. IIsta A namespace.txt 
eolajo 


namespace Mail ( 
e/elals ie HK ADOÓ z- "kosaríhajo.lu!" : 
Slevel dakázlo ge át 
function jelentes (Scimzett, Sszoveg) úí 
mail(Scimzett, "Jelentes!", Sszoveg, 
ENE áonn NEE TAB (01) 5: 


EG [GÁ TELEL S SES ÁTTETT (Is 
scano MaidlseSleaval daralos 
MEUnLIL e e jelemtes ( " karontemyénajo mu", "Szárazzólal " ) ; 


2 
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hozzáférhető, míg azon kívül közvetlenül nem. Viszont elér- 
hetők, ha egy kis előtaggal fejeljük meg, azaz a névtér nevével 
és egy kettőzött kettősponttal. A névtér előtagot és az utána 
következő változó-, állandó-, függvény-, illetve osztálynevet 
hívjuk az objektumközpontú világban , minősített névnek". 
Ilyen formában nemcsak a névtereken kívül tudunk hozzáférni 
az azokon belül létrehozott elemekhez, de ilyen módon az 
egyik névtérből át is nézhetünk a másikba. 

A PHP-értelmezőnek az sem okoz gondot , ha névterünket 
esetlegesen több darabban hozzuk létre, azaz ugyanazt a név- 
teret akár több állományban is megnyithatjuk, hogy elemeket 
pakoljunk bele. A névterek egymásba is ágyazhatók, azaz 
névtereken belül is létrehozhatunk külön névtereket. A kívül- 
ről való hivatkozáshoz a minősített névben a szülőnévtértől 
kezdve a teljes névtércsaládfát le kell írnunk. A névtérhivat- 
kozásokat azonban egymástól csak egyszeres kettősponttal 
szükséges elválasztanunk (lásd az 1. listát). 


3. lista Az object-overloading.txt 
c?php 


class Gyenge pelda tulterhelesre ( 


. Call(Sfuggveny, Sparameterek) ( 


KARMESTER eleszeny — "tuüukroz") ( 
MENTE 
(185-numeric ( Sparameterek[0])) í( 


ég CT VANTBL NAT tletlln ÉS 

— tükröz szamot 

s (Sparameterek[I0]); ) else í( 
return Selmia-s 

stukroz szoveget 

mm (Sparameterek[0] ) ; 


jorivate tumctiomn eukroz szamot lSszam 1 
retura 0 - Sszam; 


jövíivate tumcetiom 
tukroz szoveget (Sszoveg) 1 
return sttrev(Sszoveg) ; 


fels 


Egyelőre még semmi sem biztos... 


A PHP eljövendő új változatáról még nem sok biztosat lehet elmon- 
dani, bármi és bármikor megváltozhat a végleges kiadásig. Néhol 
igen hosszúra nyúlt viták következményeképpen a dolgok megerő- 
södnek, eltűnnek vagy megváltoznak. A cikk írása közben például 
kiderült, hogy egyre kevésbé valószínű, hogy a névterek bekerülnek 
a végleges ötös változatba. Még ez a játszma sincs lejátszva, s0- 
kan kardoskodnak a dolog mellett, de vannak erős érvek az elha- 
gyása mellett is. Jelenleg az utóbbi áll nyerésre. A nehézség a nem 
teljesen tökéletes megvalósíthatóságban rejlik. Az egyik ellenérv 
szerint: írásmódját tekintve a , (feltétel) ? ha igaz : ha hamis" meg- 
oldással is ütközik a névtereket egymástól elválasztó kettőspont 
használata. Ez a kódba történő kisebb belenyúlással a megfelelő 
helyeken kiküszöbölhető. De természetesen nem csak ez a gond 
vele. Csekély sebességcsökkenés is jár a dologgal, és a sok hát- 
rány mellett többek szemében egyre inkább eltörpülnek a névterek 
által nyújtott előnyök. Mindenesetre most sem tartják valószínűt- 
lennek, hogy a névtértámogatás bekerüljön az új kiadásba, de 
ehhez egyelőre hiányzik a vállalkozó szellem: nincs aki választ 
tudna adni minden egyes felmerülő nehézségre. Reménykedjünk. . . 
Egy másik változás a MySOL-támogatásban lesz. A PHP és a MySOL 
együttműködésének nagy hagyományai vannak. Egyes híresztelé- 
sekkel szemben az igazság az, hogy ez így is fog maradni. Mindössze 
annyi módosul, hogy a PHP a MySOL-támogatást illetően egy régeb- 
bi állapotba kerül vissza, azaz mindenképp külső mysg/ függvény- 
könyvtárra lesz szükség. Erre a MySOL és a PHP felhasználási szer- 
ződésbeli különbségei miatt került sor. Nagy nehézséget a dolog nem 
jelent. Egyedül annyi pluszmunkával fog járni, hogy fordításkor a 
—-wWiLth—-msölleamysen könyvetév elérhetőséges 


létezik destruktor, pedig az is hasznos eszköz lehet a tarso- 


lyunkban. Mielőtt egy objektum megsemmisül, esetleg érdemes 


lehet még egy-két rutinfeladatot végrehajtatni, ilyen például a 
naplózás, esetleg a hibakeresésben segítő adatok kiíratása. Erre 
jelenleg nincs lehetőség. A Ct -4-féle -Osztálynév ( ) 
függvény létrehozása sem segít. A fenti feladatokat ugyan egy 
register shutdown function() függvényhívás segítsé- 
gével is elvégezhetjük, de ekkor a záró műveletsor semmiféle 
közvetlen kapcsolatban nem lesz objektumunkkal. 

Mit hoz a jövő? Egy új létrehozó-, illetve megszüntető-mega- 
dási lehetőséget. Az 5-ös változattól felfelea — construct () 
ésa — destructc() tagfüggvények fognak gondoskodni az 
induláskori és a megsemmisülés pillanatában elvégzendő 
feladatok biztosításáról. Értelemszerűena — construct () 
tagfüggvényben tudjuk megadni az éledéskori alapállapotot, 
a — destruct ( ) -ban pedig az objektum megszűnésekori 
feladatokat tudjuk meghatározni. 

Miért jobb ez az elnevezésmód? legyük fel, hogy egyre 
növekvő munkánkban megg szeretnénk változtatni az egyik 
osztályunk nevét. Ekkor hibalehetőséget jelenthet az, ha elfe- 
lejtjük a létrehozót is átnevezni, követve a névváltozást. Más- 
részt előfordulhat olyan eset is, hogy leszármaztatott osztá- 
lyunk egyik tagfüggvényéből akarjuk meghívni a szülőobjek- 
tum létrehozóját. Ez a jelenlegi felállás szerint csak akkor 
oldható meg, ha a szülőobjektum neve ismert. Ez viszont nem 
feltétlenül egyértelmű. Az új elnevezés használatával viszont 
minden esetben meg tudjuk célozni a szülő létrehozóját. 
lermészetesen nem kell megijedni, a PHP5 telepítése után 
nem kell a létrehozó függvényeket az összes osztályunk for- 
rásaiban azonnal átnevezni. A visszafelé való csereszabatosság 
szem előtt tartásával a , régi", osztálynévvel megegyező létre- 
hozó kerül (létezése esetén) végrehajtásra, ha a PHP nem lel 


kapcsoló beállítására is szükség lesz. 


Változások az objektumkezelésbhen 

Az PHP 5-ös változatának megjelenésével nagy lépést tesz 
előre az objektumtámogatásban is. Jelenleg elég kevés és 
tökéletlen megvalósítás áll csak rendelkezésre, ami azért így 

is sok mindenre elég. A jelenlegi kódoknak az új értelmezővel 
is lehetőleg ugyanolyan jól kell futniuk, így az sem mindegy, 
hogy milyen módon változnak meg a dolgok. 

Az egyik sokak által és régóta várt módosítás az objektum 
értékként való átadásának megvalósításában történt. A korábbi 
(jelenlegi) változatokban ugyanis a függvényértékként átadott 
objektumból egy teljes másolat készült, amely önálló életet élt, 
majd a függvénnyel együtt megszűnt létezni. lLöbb okból sem 
jó ez így: egyrészt a függvény által kezelt objektum változásai 
nem hatnak vissza az eredetire (márpedig ez lenne az üdvö- 
zítő), valamint felesleges processzor- és memóriaterhelést is 
jelent ez egyben. Ez a gond eleddig is megoldható volt, ha 
magunk gondoskodtunk a referenciahivatkozás megfelelő 
helyekre történő biggyesztésével, de a nagy többségre elmond- 
ható, hogy fogalma sem volt a kérdésről (csak szép csöndben 
több memóriát evett a PHP mint kellett volna). 

A PHP ötös változata már másképp fog bánni az objektum típusú 
értékekkel, ugyanis önműködően referenciaként adja át őket. 
Hasonlóan fontos változás történik az objektumok létrehozó, 
illetve megszüntető (constructor/destructor) függvényeivel kap- 
csolatban. Létrehozó most is létezik a C-t nyelvben is ismert 
formában. Az osztály nevével azonos elnevezésű függvény 
hivatott az új objektum születésekor az előkészületeket meg- 
tenni, a változóknak alapértelmezett értéket adni. Viszont nem 
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a — constructw() tagfüggvény nyomára. 


Újdonságok az objektumkezelésben 


A  cilone() 

Azzal a lépéssel, hogy az 5-ös változattól kezdve — ha 
tetszik, ha nem — másolat helyett hivatkozás adódik át a 
függvények számára értékként, elesünk attól a néha azért 
szükséges lehetőségtől, hogy mégiscsak egy teljes, az ere- 
detivel azonos, de innentől önálló életet élő objektumot 
hozzunk létre. A feladat megoldására szolgál a minden 
objektummal együtt járó tartozék a — clone ( ) tagfügg- 
vény. Példának okáért eztán függvényértéknek adott igény 
esetén nem a $Dol1y objektumváltozót adjuk meg, hanem 
a SDolly-3  clonec() által létrehozott másolatra való 
hivatkozást. 

No, azért ne elégedjünk meg ennyivel! A , clone() függ- 
vény az osztályban ugyanis egy saját, hasonnevű függvény- 
nyel felülírható, ami átveszi a szerepét. Így teljes vezérlést 
nyerhetünk afelett, hogy mi és milyen módon kerüljön 
átadásra a klónozás során. A dolog hogyanja: a függvényen 
belül két objektumhivatkozás is rendelkezésre fog állni 
ehhez. Egyrészt a megszokott S$thi s, amely már a klóno- 
zás termékére fog mutatni, míg a másolás forrását a Sthat 
objektumváltozóban kapjuk meg. Innentől ránk van bízva, 
mit és hogy teszünk át Sthat-ból Sthis-be, valamint 
miféle egyéb tevékenységeket folytatunk még eközben. 

A  call() 

Az új Zend-motor további újdonságokatis hoz. A , call () 
névre hallgató tagfüggvény segítségével minden olyan 
eljáráshívást elkaphatunk, ami mögött nem áll a névnek 
megfelelő tagfüggvény, esetleg csupán nem érhető el 
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4. IIsta A static.txt 
EgJonp 


class Math ( 
Siucimakeletloltietessan —- 3.1415926536:5 
static public alsüssrsszan lk 
it (Sszam 5 NUDI 
Tett ur amsesszenme 
)]) else ( 


retura 0 - Sszams 


b 


Spi erteke - Math::SPI; 
Sabszolut ertek - Math: :abs(Svalamennyi ) ; 


E 


kívülről. Amennyiben létrehozunk egyilyen , call() 
névre hallgató tagfüggvényt, az minden olyan esetben 
működésbe lép, ha a meghívott eljárás nem létezik vagy 
nem hozzáférhető. A függvénynek két értéket kell befogad- 
nia: az elsőben érkezik a próbára tett eljárás neve, a máso- 
dikban pedig tömb formájában a függvényértékként mega- 
dott adatok futnak be. A dolog több mindenre is jó. Egy- 
részt így magunk határozhatjuk meg, hogy mi történjen 
olyankor, ha valaki nem létező függvényt próbál meghívni. 
Ennél viszont sokkal hasznosabb alkalmazási lehetősége is 
létezik ennek az eszköznek. 
Ha nem is olyan egyszerű és önműködő formában, de létre- 
hozhatjuk saját túlterhelt függvényeinket. Mit is jelent ez? 
A túlterhelt függvénynevek olyan nevek, amelyek mögött 
több megvalósítás is áll, és annak függvényében hívódik 
meg egyik vagy másik függvény, hogy épp milyen típusú 
és számosságú értéksort kapott. C-t --H-ban, mivel az fordított 
és erősen típusos nyelv, a dolog viszonylag egyszerűen kivi- 
telezhető. Ott egy adott függvényt nemcsak a neve, de a pa- 
raméterezhetőségének a mikéntje is azonosít, így nem gond 
két különböző függvényt azonos néven létrehozni. A PHP 
viszont egy fordítás közben futó parancsnyelv, így a Ct 4- 
féle módszer megvalósíthatatlan A — cal1() függvényt 
mankónak használva azonban a dolog mégiscsak megold- 
ható osztályokon belül, hiszen abból - az értékek típusának 
és számának megvizsgálása után - tetszőleges függvény 
meghívható. Szemléltetésül egy példa, ahol a hosszú nevű 
osztályunk tukroz ( ) tagfüggvénye a valóságban nem 
létezik, azt két másik tagfüggvény helyettesíti: a 
tukroz szamot () ésa tukroz szoveget ( ) saját, belső 
(private) függvény (hogy jelen esetben mit jelent a belső 
szó, arról egy kicsit később lesz szó). A két függvény közül a 
megfelelő meghívásáról -— a kapott érték megvizsgálása után 
-a — cal1l() gondoskodik. 

e A  get(), set () 
Az objektumoknak a tagfüggvények mellett léteznek egyéb 
sajátjai is, például a saját változói. És léteznek bizony 
változók, értékek, amelyekkel az adott objektum nem 
rendelkezik. Az ilyenekhez való sikertelen hozzáférések 
esetére vethetjükbea  get() ésa  set() függvényt. 
Az előbbi a nem létező változók olvasásakor, a másik pedig 
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5. lista Az abstract.txt 
c?php 


absttact ellass ATLaláztetetltki 
éles e e eleleütmtietelsiton vajzol() 


class Haromszog extends Alakzat ( 
INVNAS E NKOANNSE I ZOL() ( 
// rajzolunk egy haromszoget 


J 


class Kor extends Alakzat ( 
tumametion rajzol(l) ( 
// Trajzolumk egy kort 
J 


a. 


ezek írásakor lép működésbe, csakis akkor, ha létrehozunk 
ilyen függvényeket. A dolog tehát kísértetiesen hasonlít a 
. Call() esetére. A . set () meghívásakor két értéket 

is fogadnunk kell. Az elsőben a nem talált vagy nem nyilvá- 
nos változó nevét kapjuk meg, amibe adatot próbáltak 
kívülről adagolni. A másodikban pedig a beállítani kívánt 
értéket. Hogy mit kezdünk ezekkel az adatokkal, az már 
képzelőerő kérdése. A . get () esetén egyetlen fogadni- 
való értékünk van: az olvasni próbált változó neve. 


Private, Protected, Public 

A fenti szavak sem csengenek ismeretlenül a más nyelvektől 
érkezők számára. Ilyen előtagokkal ruházhatunk fel minden 
osztályon belüli változó- és függvénymeghatározást. A leg- 
utóbbi, a public ezek közül a PHP számára eddig is követett 
módszert jelenti, azaz jelenleg minden osztályon belül létre- 
hozott tagfüggvény és változó elérhető kívülről. A PHP5 hasz- 
nálatba vételétől kezdve az osztályon belüli elemek hozzáfé- 
rését is finomszabályozhatjuk. A private előtag használatával 
(ezt mind változómegadás, mind függvénymeghatározás elé 
odabiggyeszthetjük) levédhetünk bizonyos elemeket a külső 
meghívástól, olvasástól, illetve módosítástól. Az osztályon 
belüli tagfüggvények ettől függetlenül továbbra is hozzáférnek 
mindenhez. A belső (private) függvények használatára volt 
példa a többértelmű, túlterhelt tagfüggvény megvalósítását 
bemutató listában, ahol minden, az értékektől függő megvalósí- 
tásért felelő függvény védett a külső, közvetlen meghívástól. 

A teljes külvilágtól való elzárás és a teljes nyilvánosság között 
akad még egy átmeneti lehetőség. Előfordulhat, hogy bár a köz- 
vetlen külső meghívás nem kívánatos, az adott osztályt kibővítő 
gyermekosztályokból erre mégiscsak szükség lehet. Az ilyen 
hozzáférési forma a védett, azaz protected típusú elérési mód. 
Ha ilyen előtagot biggyesztünk egy érték vagy függvény megha- 
tározása elé, az az osztályból származtatott összes gyermekosz- 
tályból (de csakis onnan) ugyanolyan jól hozzáférhető lesz. 


Static 
Megeshet, hogy egy osztály olyan elemekkel is rendelkezik 
- legyen az függvény vagy éppen egy változó -— amelyhez 


6. lista Az exception.txt 
Saolaijo 


(emészt 
if (!mail(Scim, Stema, Sszoveg)) 1 
tlarow new NEECGCjojBtKomá ezákevzéti 
elküldése sikertelen! ) ; 


) 
iacatch (Except uiéinscretilki 

SCiosedos sulyos kivétel 2 €/los" Se- 
5-getMessage ( ) Kim 

echo "A hibás sors " Se-sGetFPile( ) 
", ! Se-sgetline() . ". sor"; 
) 
És 


anélkül hozzá lehet férni vagy esetlegesen meg lehet hívni, 
hogy az adott osztályt egy objektumban példányosítanánk. 
Ez olyankor lehetséges, amikor például egy adott függvény 
kimenetére az adott objektum pillanatnyi állapota egyáltalán 
nincs hatással. Szemléltetésül tekintsük meg a 4. listát. 


Objektumhivatkozások önműködő feloldása (dereferenciny) 
Objektumaink éppen más objektumokat is tartalmazhatnak, 

és függvényértékként adhatják vissza őket. Ilyenkor a jelen 
lehetőségek között egy objektumtól visszakapott objektum egy 
tagfüggvényét meghívni két lépésben megy csupán. A PHP5 
ebben is hoz némi változást. Az eddig csak ilyenformán 
működő programsorok 


Scsap - SLeny-scsap noveszt-( ) ; 
Scsap-skapaszkodik ( ) ; 


az ötös változattól kezdve ezzel a sorral lesznek helyettesíthetők: 
SLeny-:scsap noveszt () -—skapaszkodik ( ) ; 


Absztrakt osztályok 

A legtöbb osztály, amelyből további osztályokat származtatunk, 
önmagában is hasznos, példányosításra méltó típus. Létezik 
más nyelvekben, azonban a bázisosztálynak egy olyan fajtája, 
ami önmagában semmire sem jó, kizárólag más osztályok 
közös alapjaként szolgál, egyben megfogalmazva azok közös 
tulajdonságait. Az ilyen önállótlan bázisosztályokat absztrakt 
osztályoknak is szokás nevezni. 

Egy osztályt meghatározásakor az abstract előtag használa- 
tával tudjuk megfosztani az önálló lét lehetőségétől. Az ilyen 
osztályok példányosítási kísérletei rendre kudarcot fognak 
vallani, csakis az ezekből származtatott alosztályok számára 
lehetséges az önálló lét. A teljes osztályon belül lehetnek helyben 
kifejtett tagfüggvények, de ezek külön is rendelkezhetnek az 
abstract előtaggal, ami annyit jelent, hogy az adott függvény 
kifejtése csak a származtatott osztályban fog megtörténni (de ott 
kötelező jelleggel, hiánya pedig hibaüzenethez vezet). Lássunk 


Lf a 


egy példát egy absztrakt osztályra és két bővítményére (5. lista)! 
Közös felület 


A PHP4-nek az a korlátja, hogy egyszeres öröklődésre nyílik 
csak lehetőség, a továbbiakban is fennmarad. Ez annyit 
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jelent, hogy egy bázisosztályt kiegészítő gyermekosztály 
nem szolgálhat további gyermek bázisaként. Ily módon az 
absztrakciónak is megvannak a maga korlátai. A gond enyhí- 
tésére szolgál a közös felület (interface) létrehozásának a 
lehetősége. Egy ilyen felület egy olyan absztrakt osztálynak 
felel meg, amelynek minden tagfüggvénye is absztrakt for- 
mában (helyben nem kifejtve) létezik. A kulcsszavak, amikre 
a felületekkel kapcsolatban szükségünk van, az interface 
és az imolements. Ezek rendre a hagyományos osztályok 
class és extends szavainak felelnek meg. A felületek nagy 
előnye, hogy a megvalósítás (implements) még nem számít 
származtatásnak, így a megvalósításra szánt osztályból még 
származtathatók gyermekek. 


Több szülő közös gyermeke 

Kellemes új lehetőség lesz az is, hogy egy származtatott 
osztályt több osztály közös gyermekekért is létrehozhatunk, 
vagy akár több felületet valósítunk meg egy osztályban. 

A dolog trükkje mindössze annyi, hogy az extends és 
imolements kulcsszavak után nem egy, hanem vesszővel 
elválasztva több bázisosztály/felület nevét adjuk meg. 


Kivételkezelés 

Általános nehézség az osztályokkal kapcsolatban, hogy a 
különféle osztálykönyvtárakat létrehozó programozók ugyan 
pontosan be tudnak határolni hibákat, de nem feltétlenül 
tudják, hogy mit kezdjenek vele. Ugyanígy az ilyen osztály- 
könyvtárakat felhasználó programozók már tudják, hogy 
melyik hibával mit kezdjenek, de nem tudják közvetlenül fel- 
deríteni őket. Sokszor szükség van rá tehát, hogy a hiba felde- 
rítésének és kezelésének helye (és szintje) ne okvetlenül legyen 
ugyanaz. Az ilyen hibák egységes kezelésére nagyszerű eszköz 
a kivételkezelés. És bizony, a kivételkezelés hármasa - a try, 
throw, catch csapat — is felüti a fejét a PHP következő nem- 
zedékének kiadásában. Innentől pontosan meghatározhatjuk, 
hogy mit tartunk hibának, és hol és milyen módon óhajtjuk 
kezelni azt. Ráadásul azt az előnyét is élvezhetjük, hogy ilyen 
módon teljes mértékben elkülöníthető a , hasznos" kód és a 
hibák kezeléséért felelős kód. 


A cikkhez tartozó listák megtalálhatóak az 51. CD Magazin/PHP 
könyvtárában. 


Heiglig (Cece) Szabolcs (cececophphost.hu) 
Veszprémben él. Hobbija, kedvenc időtöltése 
és munkája Is a programozás. Szabadidejében 
hajlamos kerékpárra pattanni, vagy baráti 
társaságban szerepjátékokkal foglalkozni. 





A legfrissebb fejlesztői PHP5 a 
2 http://snaps.php.net címről gyűjthető be. 

A Zend-motorról és változásairól több cikk és GYIK is szól 
9 http://zend.com 

A PHP5 új fejlesztéseinek folyamatos és teljes leírását 
megkísérlő cikk a 3 http://pbhpvolcano.com/articles/ 
php5 címről tölthető le. 
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Programhonositás a gettext csomaggal 


Azt mondják, hogy a Microsoft annak idején azzal hódította meg a piacot, 
hogy a Windows 3.1-et a világ szinte minden nyelvén hozzáférhetővé tette. 
Ezáltal a számítástechnika széles rétegek számára lett elérhető. 


Linux terjedését gátló egyik fő ok régebben ugyanez 
volt. Nem várható el, hogy a gépet csak egyszerűen 
használni kívánó felhasználók az angol nyelvet is 
ismerjék. Sőt a számítástechnika szaknyelvében rengeteg olyan 
kifejezés akad, amit még az angolul egyébként jól tudóknak is 
külön meg kell tanulni. De a nemzetközi irodalmi művek is 
csak akkor válhattak egy nyelvi kultúra részévé, ha az adott 
nyelven is elérhetők lettek (gondoljunk csak a Biblia-fordítá- 
sokra vagy Shakespeare műveire). 

Igaz, az internet térhódításával néhány éven belül eljuthatunk 
oda, hogy az angol nyelvtudás olyan természetes lesz, mint a 
jogosítvány, mégis, egészen más érzés az anyanyelvünkön értő 
programmal dolgozni. Ezt a kereskedelmi programok készítői 
is pontosan tudják. 

Az elmúlt években több nagy fajsúlyú program (KDE, Gnome, 
OpenOffice, Mozilla) magyarítása is nagy nyilvánosságot 
kapott. Bár Magyarország kis ország, és a honosítás előnyeit 
hasznosító felhasználók száma aránylag alacsony, e programok 
magyarra fordítása nagy előrelépés a Linux elterjedésében. 

A honosítás olyan munka, amit — a programozói tudással ellen- 
tétben — csupán felhasználói ismeretekkel is el lehet kezdeni, és 
ez tovább növeli a Linux fejlesztőinek táborát. S mivel többen 
magukénak érzik a honosított programot, még többen vannak, 
akik a barátaikat is meg akarják győzni arról, hogy , ez a jobb, 
ezt használd!" Izgalmas (s megmosolyogtató) látni azt a lelke- 
sedést, amellyel a sokszor avatatlan újságírók a Linuxról írnak 
- önmagában az a tény, hogy az UHU Linux százszázalékosan 
magyar fejlesztés, olyasmi, amire egyszerűen büszkék lehetünk, 
és végre Magyarország is kihúzhatja magát, hogy van saját 
fejlesztésű operációs rendszere. 

A lelkesedést a megfelelő mederben tartva valóban minőségi 
honosítások jöhetnek létre. A 3 http:/forditas.fsf.hu/html/ 
Utmutato.html címen részletes nyelvi útmutatót olvashatunk 
Koblinger Egmont és Tímár András jóvoltából. Hasznosnak és 
fontosnak tartom a Linuxvilág Szótár rovatát is, amely szintén 
a nyelvi egységesítés felé mutat jó irányt. 

Ha eldöntöttük, hogy csatlakozunk valamelyik program fordí- 
tásához, akkor a legegyszerűbb felvenni a kapcsolatot a fejlesz- 
tői csapattal. Előfordulhat, hogy a programhoz még nincs 
magyar fordítás, de az is lehet, hogy már létezik, csak a fordító 
esetleg már nem foglalkozik a karbantartásával. Mindez az 
olvasó számára azt sejteti, hogy a fordító munkája akár hosszú 
évekig is elnyúlhat, amint a program új szövegekkel gyarap- 
szik, esetleg bizonyos szövegrészek módosulnak benne. 
Némelyik program fejlesztői erős iramot diktálnak komolyan 
betartandó határidőkkel (ami természetesen a fordítóra is 
vonatkozhat), más programoknál a lendület kisebb, és a fordí- 
tás akár évekig is elhúzódik. Azt mindenesetre tudnunk kell, 
hogy a programozást és a fordítást is többnyire önkéntesek 
végzik, szabadidőben; ez azonban nem ad felmentést az alól, 
hogy amennyiben egy fordítási munkát elvállalunk, azt 
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felelősséggel végezzük el. A nagyobb programoknál több for- 
dítóra is szükség lehet a lefordítandó szövegek nagy száma 
miatt, így számítsunk arra, hogy csapatmunka várhat ránk. 
Bizonyos programok lefordításához komoly szakmai tudásra 

is szükség lehet. Készüljünk fel arra, hogy szinte minden prog- 
ramban akadnak olyan kifejezések, amelyeket csak akkor 
fogunk tudni lefordítani, ha a programot angol eredetijében 
már teljes egészében megismertük -— csak ezután érdemes a 
munkának teljes erőbedobással nekivágni. 


Technikai részletek 

A programok nemzetköziesítésére több módszer is kínálkozik. 
Úgy tűnik, hogy a legéletképesebb és legelterjedtebb kezde- 
ményezés a GNU gettext projekt, amely jelenleg a 0.12.1-es 
változatnál tart. A 5 http:/www.kde.org/fordfag/forditas.html 
és a 5 http:/www.szabilinux.hu/forditasok/gnome-fag/ 
ilőn.html címeken elindulva jó alapokra tehetünk szert a 
témában, magyar nyelven, röviden. (A gettext hosszú, alapos 
leírása talán sokakat elriaszt ettől az egyébként nagyon kényel- 
mesen kezelhető eszköztől.) 





A gettext alapú fordítási folyamat lényege a következő: egy 
úgynevezett sablonfájlban (pl.: messages.pot) a program szerzői 
az összes lefordítandó szöveget felsorolják angol nyelven. Egy 
ilyen szöveg lehet egy-egy menü neve, esetleg egy rövid felirat, 
vagy akár egy hosszabb, több mondaton is átnyúló magyarázó 
leírás. A sablonfájlt lemásolva a fordító létrehozza a majdani 
saját nyelvű fordításokat tartalmazó fájlt (például hu.po néven), 
egy-két perc alatt módosítja a fájl legelején található leíró 
fejlécet, majd az egyes angol szövegek alá begépeli a magyar 
nyelvű megfelelőt. Ezután a szerzőknek a hu.po fájlt elküldve 

a programba már könnyen befűzhetők a magyar nyelvű üzene- 
tek (a befűzést a fejlesztők rendszerint maguk elvégzik). 
Nézzünk egy példát! A XaosS fraktálrajzoló program 3.1-es 
változatában a forrásprogram src/i18$n könyvtárában található 
hu.po fájl így indul: 


t XaoS NLS file for Hungarian language. 

t Copyright (C) 2002 Free Software Foundation, 
t Inc. 

t Zoltan Kovacs ckovzolegmath.u-szeged.husz, 2002. 
tt 

msgid "" 

msgstr "" 
"Project-1d-Version: 
"POT-Creation-Date: 


XaoS 3.1" 

2002-09-25 21:17-0200W2" 
"PO-Revision-Date: 2002-08-17 21:445020042" 
"Last-Translator: Zoltan Kovacs 

5 -kovzol8gmath.u-szeged.husz tn" 
"Language-Team: Hungarian" 
"MIMER-Version: 1.OWw" 
"Content-Iype: text/plain; 
s charset-IS0-8859-24n" 
"Content-Transfer-Encoding: 8-bitWwm" 
HT: .4./üil/ür .€:r310 

msgid "XaoS is out of memory." 
msgstr "Elfogyott a memória." 


tt: ../u1/ui.c:360 


msgid "2s 5.2f£ times (5.1fE) 32.2£ 
—frames/sec $c 31 21 31 21 ; 
msgstr "" 

"52S5.2£-szeres 2$1Ss (33S5.1£fE) 345S52.2£ kép/mo" 


" 25Sc 36051 $/S1i s$0S1 $9HSi ű 
TH: ../ü1/zui. c:361 

msgid "unzoomed" 

megett "kicsinyítés" 
t: ../ui1i/ui1.c:361 
msgid "zoomed" 
megett "nagyitás" 


2 ss /ÜL/Üt sé: 368 

tt, c-format 

msgid "Íramerate:sSfwn" 
msgstr "képfrissítés:2£M4n" 


A 7 (kettős kereszttel) kezdődő sorok megjegyzések, tartalmuk 
másodlagos. Az angol nyelvű szövegeket az msgid kezdetű so- 
rokban olvassuk, idézőjelek között. (Amennyiben a szöveg egy 
sornál hosszabb, úgy az a következő sorban is folytatható, ismé- 


4 éa 


telt idézőjelek között.) Az msgstr kezdetű sorok adják meg a 
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szöveg magyar nyelvű megfelelőjét. Látható, hogy a .po fájl első 
,éles" bejegyzése az üres " szöveghez kapcsolódik: a szabvány 
szerint az ehhez tartozó , fordítás" ad információt a hu.po fájl 
tartalmáról. (Ennek a formátuma eléggé kötött, és hibaüzenetet 
kapunk, ha valamelyik kötelező rovatát nem töltöttük ki helyesen.) 
Akik a C nyelvben kevésbé járatosak, azoknak könnyű a mind 
az angol szövegekben, mind a fordításukban megjelenő 
formázó részszövegeket felismerniük. Ilyen például a Wn, ami 
az új sor jele, vagy a $s és a 3£, amelyek arra utalnak, hogy 

a helyükbe egy másik szöveget vagy egy valós számot kell 
behelyettesíteni. Arra is mód nyílik, hogy a magyar változatban 
az egyes számokat, értékeket az angol eredetihez képest más 
sorrendben helyettesítsük be. Például az 


msgid "Today i1s 28 $s in the year $s." 
msgstr "A mai dátum: 23$Ss. 3$2Ss $3$1Ss." 


eredeti-fordítás párral elérhetjük, hogy az angol szöveg tükör- 
fordítása helyett a magyar szokás szerinti megfelelő jelenjen 
meg a programunkban. Munkánk során azonban többnyire 
egyszerűbb esetekkel találkozunk. Az sem baj, ha kezdetben 
nem is fordítunk le minden szöveget, csak a legfontosabbakat: 
a kihagyott esetekben mindig az angol eredeti fog a magyar 
változatban is megjelenni. Látható az is, hogy a fenti szövegek 
többnyire nem szó szerint lettek lefordítva. Ennek oka sokszor 
az, hogy a magyar nyelv logikája néha egészen más, mint az 
angolé, s így kerülőutakra kényszerülünk. 

A fordítási lépéssorozatot több grafikus segédprogram is 
megkönnyítheti. A régebben készült ktranslator program 
helyett újabban talán többen használják a pokdit többfelületes 
alkalmazást (ez ugyanis Windowson is elérhető), illetve a KDE 
alatt futó kbabel programot (1-2. kép). Akik mégis a ,fapados" 
megoldásokat szeretik, azoknak viszont teljes szívvel ajánlható 
például a Midnight Commander szövegszerkesztője (3. kép). 


A pudiny próbája 

Sokáig - akár hónapokig is - eltarthat, amíg az elkészült hu.po 
fájlunk a fejlesztők jóvoltából belekerül az időszerű változatba, 
és élesben kipróbálhatjuk. Ha azonban ügyeskedünk egy kicsit, 
már a hu.po fájl készítése közben belepillanthatunk, hogyan is 
néz ki a honosított program magyarul, akár csak részben 
lefordított szövegekkel. 


Munkafolyamat Szerkesztés Nézet Könyvjelzők Beállítások Segítség 


HEGNNESZE A 5 és 37 4 3 be BV sézbb Lefe 
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A hu.po fájlból a gettext csomag egyik segédprogramja egy .mo 
kiterjesztésű fájlt készít, amelyet fejlesztett programunk bináris 
változata könnyedén értelmezni tud. Ezt a fájlt (legyen most 

a neve ize.mo, arra utalva, hogy az , izé" nevű programot for- 
dítjuk magyarra) rendszerint a /usr/share/locale/hu HU/ 

LC MESSAGES könyvtárban helyezik el (a Linux-változatunk- 
tól és a telepített Programoktól függően ettől különböző, illetve 
ezenkívül más, hasonló nevű könyvtárak is szóba jöhetnek). 
Keressük meg a gépünkön ezt a könyvtárat, és nézzünk utána, 
hogy programjaink közül melyiknek van telepítve a magyar 
nyelvű változata. 

A fenti segédprogram neve: msgfmt, futtatása a következő 
módon javasolt: 


S msgímt -o /usr/share/locale/hu HU/ 
TC MESSAGES/1Zze.mo hu.po 


Világos, hogy ehhez rendszergazdai jogosultság is szükséges. 
Ha ilyennel nem rendelkezünk, a saját könyvtárunkban egy- 
szerűen hozzunk létre egy hu HU/LC MESSAGES alkönyvtárat, 
s oda dolgozzunk - ebben az esetben azonban lehet, hogy a 
fejlesztett programba is bele kell nyúlnunk, hogy tudassuk vele: 
a fordításokat nem az alapértelmezett könyvtárban kell keresnie. 


Égy mintapélda 

Elképzelhető, hogy egy teljesen új programot akarunk írni, 
amit nemzetközi támogatással szeretnénk ellátni. Progra- 
munk, az izé 1.0-s változatának íze.c nevű forráskódja a 
következőképpen néz ki: 


Htinclude clocale.hs 
tdefine . (szoveg) gettext (szoveg) 


main ( ) 
( 

setlocale(LC MESSAGES, ""); 
tifdef HELYBEN 


bindtextdomain("ize", getenv( "HOME" ) ) ; 


tendif 
textdomain( "ize" ) ; 
printf( ("Welcome to the program $s!"), 
m.j ze"); 
printt( "Wwa"); 
J 


Az első sorban tudatjuk a C-fordítóval, hogy a gettext csomag- 
gal dolgozunk. A másodikban egy olyan rövidítést adunk meg, 
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amellyel a későbbiekben elérhetjük, hogy minden szövegünk 
nemzetközi változataa ("szöveg") hívással is megjelenhes- 
sen (ez szabványos rövidítés, a gettext leírása is ezt a módszert 
javasolja, sőt a gettext segédprogramjai alapértelmezésben ezt 
a rövidítést támogatják). A setlocale() függvénnyel kapcso- 
lunk nemzetközi üzemmódba (lehetőség volna arra is, hogy 
például a számokat, illetve a pénznemeket is magyar szabvány 
alapján jelenítsük meg, az LC NUMERIC és LC MONETARY vál- 
tozók beállításával; erről bővebben a gettext leírásában olvas- 
hatunk). Amennyiben nincs rendszergazdai jogosultságunk, 

az ize.mo fájlt a -—/hu HU/LC MESSAGES könyvtárból olvas- 
suk majd be, ezt engedélyezzük a tti fdef és a tendif közötti 
bindtextdomain ( ) függvénnyel. A kiíratás a C nyelvben 
megszokott módon, a printf ( ) függvénnyel történik. 

Ezek után megadjuk a programunkban egyelőre egyetlen 
angol nyelvű szöveg fordítását a hu.po fájlban: 


msgid "" 
msgstr "" 
"Project-1d-Version: 
"POT-Creation-Date: 


ize 1.OW" 
2003-07-20 08:10--020042" 
"PO-Revision-Date: 2003-07-20 08:3241020042" 
"Last-Iranslator: Zoltan Kovacs 
ckovzol8math.u-szeged.huszwn" 

"LTanguage-Team: Hungarian" 

"MIME-Version: 1.OW" 
"Content-Iype: text/plain; 
"Content-Transfer-Encoding: 


charset-15S50-8859—2Wm" 
8-bitn" 


msgid "Welcome to the program Zs!" 
égett "Köszönti Önt alz] 88 brógrami" 

Az alábbiakban két Makefile olvasható. Ha van rendszergaz- 
dai jogosultságunk, használhatjuk az elsőt, máskülönben csak 

a második fog működni. A beljebb kezdett sorokat tabulátorral 
kell kezdeni. 


all: ize ize.mo 
ize: ize.C 

gcc -o ize i17ze.C 
ize.mo: hu.po 


msgímt -o 
/usr/share/locale/hu HU/LC MESSAGES/1ze.mo hu.po 
all: ize i17Ze.mo 


17e.C 
gcc 


ize: 


-o ize ize.c -D HELYBEN 


ize.mo: hu.po 
msgímt -o 
5 S (HOME) /hu HU/LC MESSAGES/ize.mo hu.po 


Ezek után adjuk ki: 


S make 
S ./ize 


Ekkor a 


Köszönti Önt alíz) ize program! 


THúnKar- BibleTime 
A File View Mainindex Window Settings Help 


D4 A MEN? 


1 Mind az egész földnek pedig egy nyelve és egyféle beszéde vala. 

2 Es lön mikor kelet felől elindultak vala, Sineár földén egy sikságot találának és ott 
letelepedének. 

3 És mondának egymásnak: Jertek, vessünk téglát és égessük ki jól; és lön nékik a tégla kö 
gyanánt, a szurok pedig ragasztó gyanánt. 

4 És mondának: Jertek, építsünk magunknak várost és tornyot, melynek teteje az eget érje, és 
szerezzünk magunknak nevet, hogy el ne széledjünk az egész földnek színén. 

5 Az Ur pedig leszálla, hogy lássa a várost és a tornyot. melyet építenek vala az emberek fiai. 
6 És monda az Úr: Ímé e nép egy. s az egésznek egy a nyelve, és munkájának ez a kezdete; és 
bizony semmi sem gátolja. hogy véghez ne vigyenek mindent. a mit elgondolnak magukban. 
7 Nosza szálljunk alá, és zavarjuk ott össze nyelvöket, hogy meg ne értsék egymás beszédét. 
8 És elszéleszté őket onnan az Úr az egész földnek színére; és megszűnének építeni a várost. 
9 Ezért nevezék annak nevét Bábelnek; mert ott zavará össze az Ur az egész föld nyelvét, és 


: 


tt 
onnan széleszté el őket az Ur az egész földnek színére y 


szöveget kell látnunk. Ha a későbbiekben akár a .c, akár a .po 
fájlt módosítjuk, egyszerűen csak a make parancsot kell újra 
kiadnunk, amivel íze és ize.mo nevű bináris fájljaink önmű- 
ködően frissülni fognak. 


Többnyelvűség 

A szép az egészben az, hogy a programunk innentől kezdve 
többnyelvű. Az egyes hozzáférhető nyelvek közül a program 
indítása előtt választhatunk: 

$ LANG-de DE; ./i1ze 

Így például németül futna a programunk, ha a megfelelő 
könyvtárban megvolna az ize.mo fájl német nyelvű változata 
(mivel nincs, a feliratok angol nyelvűek lesznek). 

Próbáljuk németül elindítani a Midnight Commandert, 

a Gimpet pedig spanyolul és csehül. 

Mostantól más nemzetiségű fejlesztők, fordítók is csatla- 
kozhatnak projektünkhöz, ha a hu.po fájlt például de.po-ra 
nevezik át, s az msgstr sorokat a megfelelő német 
fordításokkal helyettesítik. (Jobb, ha létezik egy központi 
messages.pot sablonfájl, amelyben az msgstr sorok üresek, s 
így a német fordítónak nem kell még a magyar fordítások 
kitörlésével is bajlódnia.) 

Ha egy program magyar fordításával elégedetlenek vagyunk, az 
eredeti angol szövegeket úgy jeleníthetjük meg, ha a LANG vál- 
tozót C-re kapcsoljuk át (az en EN érték ugyanúgy megfelelő). 


Tippek és trükkök 

A nemzetköziesítés éles használata számos gyakorlati kérdést 

vet fel. Ilyenek például a következők: 

e . Hogyan tehermentesíthető a fordító abban az esetben, ha 
a már lefordított szövegek időről időre részben (1-2 karak- 
terben, szóban) megváltoznak? Azaz van-e mód arra, hogy 
ezekben az esetekben a fordítónak ne kelljen minden 
megváltoztatott szöveget teljes egészében újrafordítania? 

e . Megoldható-e, hogy a C nyelvű programban előforduló 
szövegekből önműködően jöjjön létre a megfelelő sablon- 
fájl? Azaz megoldható-e, hogy a fejlesztőkre kevesebb 
karbantartói munka háruljon, vagyis a messages.pot fájlt 
robot hozza létre? 

e . Hogyan követhető nyomon, hogy a fejlesztők mely új 
szövegeket adták hozzá a program újabb változatához, és 
a fordító hogyan értesülhet a leggyorsabban arról, ha új 
szövegeket kell lefordítania? 

e . Megoldható-e, hogy már létező C-programokat gyorsan, 
önműködően nemzetköziesítsünk? 


Mindezeket a kérdéseket (és számos továbbit) a gettext fejlesz- 
tői nagyrészt megoldották, és több segédprogramot bocsátanak 
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rendelkezésünkre. Ilyen például az msgmerge program, 
amellyel a hu.po fájlt frissíthetjük az új változatú messages.pot 
fájl új üzeneteivel (esetlegesen arra is figyelve, hogy bizonyos 
szövegek időközben megváltoztak); vagy az xgettext, amellyel 
a C (vagy számos egyéb, például Java, Python vagy PHP) nyel- 
vű programból az összes angol nyelvű szöveget , kirobbanthat- 
juk", s azokból sablonfájlt szervezhetünk. Hasznos eszköz a 
gettextize is, amivel egy C nyelvű program könnyen átszab- 
ható úgy, hogy támogassa a gettext szabványt. A gyakorlatban 
a fejlesztők gyakran CVS-rendszert is bevonnak a programozói 
munkába, hogy a különböző változatok közötti eltéréseket 
könnyebben átláthassák (a nemzetköziesítéstől függetlenül is). 
A fenti kérdésekre minden egyes program fejlesztésekor vala- 
miféle választ szokás adni, de ez a projektektől függően más 

és más lehet. A megoldások többnyire a gettext használati uta- 
sításának ajánlásait követik (ám bizonyos részletekben gyakran 
el is térnek attól). Lássunk egy példát! A PostgreSOL adatbázis- 
kezelő 7.3-as változatához egy éve új felügyeleti program ké- 
szül pgAdmin3 néven. A nyelvi fordítás a fejlesztéssel párhu- 
zamosan Zajlik, azaz a fordítóknak rendszeresen új sablonfáj- 
lokat kell összefésülniük az általuk szerkesztett .po fájllal. 

A nyelvi koordinátor a 3 http:/snake.pgadmin.org/pgadmin3/ 
translation.php címen (4. kép) időről időre frissíti a sablonfájlt, 
amit a 26 fordító mindegyike, például a poEdit program 
Catalog menüjének Update from POT file lehetőségével fűzhet 
össze a Saját .po fájljával. Ezután az új és a megváltozott szöve- 
gek honosításának megtörténtével az újonnan kapott .po fájlt 
vissza kell küldeni a koordinátorhoz, aki a program hivatalos 
forráskódjában (CVS-rendszeren) is rögzíti a változtatásokat. 
Ezt az eljárást mindannyiszor meg kell ismételni, ahányszor 

a sablonfájl módosul. (A gyakorlatban a fejlesztők mindig előbb 
járnak, mint a fordítók, így fordulhat elő, hogy a magyar 
fordítás szinte egyetlen programnál sem százszázalékos.) 


A jövő 

A gettext olyannyira jól bevált, hogy számos programozási 
nyelv alapértelmezésben támogatja a használatát. Ennek elle- 
nére a bábeli zűrzavar teljes megoldása még hosszú távon is 
lehetetlen feladatnak tűnik. Évtizedek kemény munkájának 
tapasztalata alapján úgy látszik, hogy a fordítási munkafolya- 
mat csak részben tehető önműködővé. Még egy számítógépes 
program fordítása során is sokszor szinte művészi tehetség kell, 
hogy a szövegeket anyanyelvünkön szépen, pontosan, csatta- 
nósan fogalmazzuk meg. Emiatt a fordító feladata fáradságos, 
hosszú, sziszifuszi munka lehet. Ezt mindenesetre kárpótol- 
hatja az a tény, hogy a magyar fordításon felnőtt járatlan fel- 
használók kényelmesebben, nagyobb örömmel dolgoznak 
majd az adott programmal. Így a fordító közvetve igen sok 

új honfitárs felhasználót nyerhet meg nemcsak az adott prog- 
ramnak, hanem a Linuxnak is. 


Tipp: töltsük le az internetről a Biblelime programot, és telepít- 
sük mellé Károli Gáspár Biblia-fordítását (HunKar.zip). 
Keressük ki azt a részt Mózes 1. könyvéből, amelyik Bábel 
tornyának történetét meséli el (5. kép). 


Kovács Zoltán 

] (kovzolomath.u-szeged.hu) 

lanársegéd a Szegedi ludományegyetem Bolyai 
Intézetében az Analízis Tanszéken, matematikát 
és számítástechnikát tanít óraadóként a szegedi 
Radnóti Miklós Kísérleti Gimnáziumban. 
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Operációs rendszerek (14. rész) 


Sorozatunk jelenlegi témája a lemezterület-kezelés, 
a fájlrendszerek megbízhatósága, egységessége és hatékonysága lesz. 


ikksorozatunk előző részében (Linuxvilág július, 
CC 62. oldal) megismerkedtünk a fájlkezelés alapfogal- 

maival. Most már nyugodtan belevághatunk a meg- 
valósításba is. Mivel a fájlokat mágneslemezen tároljuk, a 
rendszer fejlesztőinek tulajdonképpen csak a lemez területé- 
nek kezelésével kell megbirkózniuk, ami — mint hamarosan 
kiderül -— elég nagy kihívás. 
A lemezek kezelésével sorozatunk egyik korábbi részében már 
foglalkoztunk, amikor a blokkos beviteli-kiviteli eszközöket 
tárgyaltuk. Érdemes az ott leírtakat átismételni, mivel lépten- 
nyomon hivatkozni fogunk rájuk. 
Minket most nem az eszközök érdekelnek, nem is fontos, 
hogy milyen lemezről van szó. A fájlkezelés nem más, mint 
a lemezterület-kezelés tudománya. Az a fontos, hogy milyen 
elv alapján tároljuk állományainkat a lemezen, úgy, hogy a 
tartalmukat bármikor visszaolvashassuk, felülírhassuk vagy 
letörölhessük. Ezenkívül az is nagyon fontos, hogy az egész 
folyamat gyors legyen. 
A lemezterület kezelése sok tekintetben hasonlít a memóriáé- 
hoz, csak még annál is bonyolultabb. Közös bennük, hogy itt 
is egy meghatározott méretű szabad területtel kell gazdálkod- 
nunk olyan módon, hogy a lehető leggazdaságosabban ki 
tudjuk használni. Ugyanakkor ebben az esetben felmerül egy 
olyan tényező is, ami a memóriánál nem volt számottevő. Ez 
pedig nem más, mint az idő. Ha a lemezről be szeretnénk 
olvasni egy bájtot, akkor először is az olvasófejet úgy kell moz- 
gatnunk, hogy az pontosan a felett a szektor felett legyen, 
amelyik a kívánt bájtot is tartalmazza. Egy szektor beolvasá- 
sának az ideje nem számottevő, de a fej mozgatása annál 
inkább. Míg a memória összes részét ugyanannyi idő alatt 
(gyakorlatilag azonnal) el tudtuk érni, addig a lemezek eseté- 
ben a végrehajtási idő attól függ, hogy a fej éppen hol tartóz- 
kodik. Egy jó fájlrendszernél nem elég tehát, hogy gazdaságos 
tárolást nyújt, hanem az is fontos, hogy úgy helyezze el az 
adatokat, hogy például egy fájl eléréséhez a lehető legkeve- 
sebbet kelljen mozgatni a fejet. 
Lássuk, milyen lehetőségek közül választhatunk! A virtuális 
memória esetében a szakaszolás és a lapozás volt a két meg- 
határozó módszer, a lemezeknél is használhatunk valami 
ezekhez hasonlót. Például az állományokat tárolhatjuk foly- 
tonosan, azaz egybefüggő lemezterületen. Ez elsőre nagyon 
csábító lehet, mivel a fájlok olvasása rendkívül egyszerűen 
és gyorsan megoldható, és a fejet is csak egyszer kell 
megmozdítanunk. 
Rögvest megváltozik a helyzet, amikor egy állomány növeke- 
désnek indul. A memória esetében ilyenkor nem volt semmi 
gond, a szakaszt csak át kellett egy másik memóriaterületre 
költöztetni, ahol nagyobb szabad hely állt rendelkezésre. 
Csakhogy a memóriában történő mozgatás szinte semmi időbe 
se kerül, míg a lemezekről ez nem mondható el. 
Célszerűbb, ha minden állományt egyenlő méretű blokkokra 
osztunk fel, amelyeknek természetesen nem kell szigorúan 
egymás mellett lenniük, akár össze-vissza is elhelyezkedhetnek 


64 


Linuxvilág 


a lemezen. Itt nem okozhat gondot a fájl méretének növe- 
kedése, viszont egy fájl teljes tartalmának a beolvasásakor 
valószínűleg több fejmozgatásra is szükség lesz. Mindenesetre 
a legtöbb fájlrendszer ezt a sémát használja. 


A biokkméret megválasztása 

Az odáig rendben van, hogy a fájlokat egyenlő részekre oszt- 
juk, de vajon mekkorákra? Mivel a merevlemezek cilinderekre, 
sávokra, illetve szektorokra osztottak, megpróbálhatjuk ezeket 
választani az állományok helyfoglalási egységének. 

A cilindert azonban semmiképp sem érdemes választani, mivel 
túl nagy. A nagy blokkmérettel az a gond, hogy sok kis 
állomány esetén rengeteg szabad kapacitás megy veszendőbe. 
Főleg, ha egy olyan rendszerről van szó, amelyik rengeteg apró 
fájllal dolgozik (például jellemzően ilyenek a Unixok). 

Nagy a cilinder? Semmi gond, nézzük a szektort, ami sokkal 
kisebb. Valójában a szektor nemcsak kicsi, hanem túl kicsi 
ahhoz, hogy eszményi blokkméretnek választhassuk. Ez ugyan 
a lehető legkevésbé pazarló megoldás, viszont a nagy állomá- 
nyok rengeteg kis blokkból állnának, s ezek valószínűleg a 
lemezen egymástól jó távolra helyezkednének el. Egy ilyen 
állomány beolvasása a sok pozícionálás miatt próbára tenné 

a felhasználók türelmét. 

Egyből két tanulságot is levonhatunk. Az első, hogy helyfog- 
lalási egységet semmiképp sem a lemez , fizikai" egységei 
alapján érdemes választani. A másik pedig az, hogy minél 
kisebb a blokkméret, annál jobb a tárolási hatékonyság, viszont 
a fájlrendszer időhatékonysága annál rosszabb. Ez az állítás 
fordítva is igaz. 

Mekkora lehet vajon a tökéletes blokkméret? Hát valahol a 
nagyon nagy és a nagyon kicsi között. Ez a nyilván megegye- 
zésen alapuló választás nagymértékben függ a rendszertől, 
illetve attól, hogy kik használják. A legújabb kutatások minden- 
esetre azt mutatják, hogy a felhasználók átlagosan egyre 
nagyobb állományokat birtokolnak, tehát minden jel arra utal, 
hogy a nagyobb blokkméreteké a jövő. 


Szabad blokkok 


Amikor új állományt hozunk létre, vagy egy régihez újabb 
dolgokat írunk hozzá, akkor a rendszernek szabad blokkot kell 
foglalnia. Ehhez azonban fontos tudnia, hogy az összes blokk 
közül melyik szabad, és melyik nem. 

Erre két elterjedt módszer létezik. Az első esetben a szabad 
blokkok címeit is blokkokban tároljuk, és ezeket egy láncolt 
listába fűzzük. Ez az úgynevezett láncolt lista, amit úgy 
képzelhetünk el, hogy van egy blokk, amelyben csak szabad 
blokkok címeit találjuk. Az utolsó helyen lévő cím azonban 
nem egy szabad blokk címe, hanem a következő olyan blokké, 
amelyik szabad címeket tartalmaz. 

A másik az úgynevezett bittérképes módszer. Itt minden 
blokkhoz egy bitet rendelünk, ami azt jelzi, hogy szabad-e 
vagy sem. 

Mindkét módszernek akadnak hátrányai. Vegyünk egy 


1 GB-os merevlemezt 1 KB-os blokkmérettel - ez azt jelenti, 
hogy körülbelül egymillió blokkot tartalmaz. Láncolt listás 
megoldáskor, ha a teljes lemez üres, körülbelül négyezer 
blokkot (4 MB-ot) kell szánnunk az üres blokkok tárolására 
(32 bites blokkcímek esetében). A bittérképesnél az egész csak 
egymillió bitet, azaz pontosan 128 KB-ot foglal el. 

A bittérképes megoldás jobbnak tűnhet, mint a láncolt listás. 
Ez azonban csak akkor igaz, ha lehetőség nyílik az egész 
bittérkép memóriában tárolására. Ma már memória ugyan 
sok van, de például egy 80 GB-os lemez esetében ez már 

10 MB-unkba fog kerülni. Ez már elég 

nagy ahhoz, hogy ne tartsuk az egész 

bittérképet a memóriában. 

legyük fel, hogy a memóriában 
mindig csak egy blokknyi bittérképet 
tartunk. Ha szabad blokkra van 
szükségünk, de a bittérképben nincs 
ilyen, akkor a rendszernek a bittér- 
kép egy másik szeletét kell beol- 
vasnia. Azt azonban semmi sem 
garantálja, hogy abban már talá- 
lunk szabad blokkokat. Ha a 
merevlemezünk már csaknem 

tele van, azaz kevés a szabad 

blokk, megeshet, hogy szinte 

az egész bittérképet végig kell 
olvasnunk. A láncolt listás 
megoldásnál azonban csak Éz 
egyetlen blokkal kell ezt meg- ba 
tennünk, és máris nyertünk 
újabb 255 szabad blokkcímet. 

Ne felejtsük el azt sem, hogy 

a láncolt listás megoldásnál a 
lemez betelítésével csökken azon 
blokkok száma, amelyet a szabad blokkok nyilvántartására 
kell használnunk. Az 1 GB-os merevlemez esetében a bittér- 
képnek mindig fent kell tartanunk szabad 128 kilobájtot, 
míg a láncolt listásnál egyet sem, feltéve, ha csurig töltjük 
merevlemezünket. 


A fájlrendszer hatékonysága 

A merevlemezek átlagosan százezerszer lassabbak, mint 

a memória. Ez az érték attól is függ, hogy a fej éppen hol 
tartózkodik, illetve mennyi adatot szeretne a felhasználó 
kiolvasni belőle. A memóriát például bájtonként, egyes 
rendszerekben szavanként címezhetjük, lemezek esetében 
azonban mindig az egész blokkot be kell olvasnunk, illetve 
ki kell írnunk. Ez nem szerencsés akkor, amikor csak egy-két 
bájtra lenne szükségünk. 

Ezért a lemezterület kezelésnél előtérbe kerül a hatékonyság 
fogalma, azaz ki kell találnunk olyan módszereket, amivel a 
lemezműveleteket némileg felgyorsíthatnánk. Erre kétféle, ám 
együttesen használható megközelítés is létezik: egyrészt a 
lehető legkevesebbszer forduljunk a lemezhez, másrészt, ha 
már meg kell tennünk, akkor csökkentsük a lemezműveletek 
idejét. Az első célkitűzést egy gyorsítótár (cache) bevezetésével 
megvalósíthatjuk. Egy szektor beolvasását ugyan nem tudjuk 
felgyorsítani, ha viszont úgy rendezzük a blokkokat a lemezen, 
hogy a fejet ne kelljen minden kérés alkalmával pakolgatni, 
akkor a második feladatot is teljesíteni tudjuk. 

A gyorsítótárnál alkalmazott elv sok tekintetben hasonlít a 
lapozott memóriáéhoz. Ha egy keresett blokk bent csücsül a 
gyorsítótárban, akkor a kérést anélkül ki tudjuk szolgálni, hogy 
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a lemezhez fordulnánk. Ha nincs, akkor a gyorsítótárból egy 
blokkot kiválasztva ki kell írnunk a lemezre, majd betenni a 
helyére azt, ami éppen kell nekünk. Ehhez előbb ki kell válasz- 
tanunk, hogy melyik legyen az a blokk, amelyiknek távoznia 
kell. Ennek eldöntésére használhatjuk a lapozási algoritmusok 
valamelyikét, például az LRU-t vagy a FIFO-t. 
A helyzet azonban nem ilyen egyszerű. Ha , színtiszta" 
lapozási algoritmusokat (például az LRU-t) használunk, 
akkor könnyen kerülhetünk kellemetlen helyzetbe. Képzeljük 
el azt a helyzetet, amikor módosítunk egy, a fájlrendszer 
szempontjából alapvető fontos- 
ságú blokkot, például olyat, 
ami fájlleírót (inode) tartalmaz. 
A módosítás a lemezen csak 
akkor könyvelődik el, ha 
az algoritmus a gyorsítótár- 
ból ezt a blokkot takarítja 
ki. Ha eközben esetleg egy 
rendszerösszeomlás követ- 
kezik be (vagy áramszünet, 
vagy hasonló katasztrófa), 
a fájlrendszerünk 

sérülni fog. 

Ezt orvosolhatjuk 
akképpen, hogy bizo- 
nyos blokkokat (ame- 

lyek kiemelt szerepet 
játszanak a fájlrend- 
szer életében) egyből 
kiírunk a lemezre, 
vagy az LRU-lánc 
elejére teszünk, tehát 
a következő cserénél 
az a blokk lesz az, amelyik kiíródik. 
Az adatblokkokat csak akkor érdemes cserélnünk, ha várha- 
tóan rövid időn belül nem lesz rájuk szükségünk. Az úgyne- 
vezett csonka adatblokkok mindig az LRU-lánc végére kerül- 
nek, mivel ezek hamarosan kellenek, hiszen valószínűleg 
valamelyik alkalmazás írni fog bele. 
Előfordulhat olyan eset, hogy egy adatblokk sosem kerül az 
LRU-lánc elejére, azaz nem kerül kiírásra. Jellemzően ilyen 
eset, ha valaki szövegszerkesztővel dolgozik. Például e cikk 
szerzője e sorok írásakor már harmadik órája szenved a 
cikkével, és mivel más lemezműveleteket végrehajtó programot 
nem futtat, a dokumentumot tartalmazó blokk minden bizony- 
nyal nem kerül ki a gyorsítótárból. Ha a szerző egy bután 
megtervezett operációs rendszert használna, és esetleg áram- 
szünet következne be, akkor minden bizonnyal háromórányi 
munkája veszne el. Ezen még az sem segítene, ha az önmű- 
ködő mentési szolgáltatás be lenne kapcsolva. 
Szerencsére a szerző rendszerében (és minden Unixban) 
van egy SYNC nevű rendszerhívás, ami az összes gyorsí- 
tótárban lévő blokkot kiírja a lemezre. Ez a rendszerhívás 
mindig végrehajtódik, amikor egy lemezegység leválasztá- 
sára készülünk, de ez még kevés. A SYNC-nek akkor van 
igazán haszna, ha valaki folyamatosan végrehajtja. Ezért 
az összes Unix induláskor egy folyamatot indít el (amelynek 
általában update, vagy rendszertől függően valami hasonló 
neve van), ami nem tesz mást, mint hogy félpercenként 
meghívja a SYNC-et. Rendszerösszeomláskor itt is bekövet- 
kezhet némi adatvesztés, de csak annyié, amennyit az utolsó 
30 másodpercben alkottunk. 
Létezik azonban olyan rendszer is, amelyik minden módosított 
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blokkot egyből kiír a lemezre (ez az úgynevezett írásáteresztő 
gyorsítótár). Ilyen például az MS-DOS. Ezért van az, hogy DOS 
alatt mindenféle komolyabb következmény nélkül cserélget- 
hetjük a hajlékonylemezeinket, míg például Linux alatt először 
le kell azt választanunk. 

Ennek a módszernek az a hátránya, hogyha karakterenként 
írjuk az állományt, akkor annyi lemezműveletet kell végrehaj- 
tani, ahány bájtot kiírunk. Ez sokkal lassabb, mintha először 
összegyűjtenénk a változásokat a gyorsítótárba, majd egy SYNC 
rendszerhívás következtében egyetlen lemezművelettel az 
egészet kiírnánk. (Ezért, akik DOS alá fejlesztettek, gyakran 
programon belüli gyorsítótárat használtak. Ennek az volt a 
módja, hogy a kiírandó karaktereket először egy tömbbe tették, 
és ha az megtelt, akkor az egész tömböt kiíratták, majd indul- 
hatott az egész elölről.) 

Meg kell jegyeznünk azonban, hogy az MS-DOS-nak ez nem 
tervezési hibája, valójában kifejezetten ilyenre alkották. 
Ugyanis ezt a programot a személyi számítógépekre tervezték, 
még azokban az időkben, amikor a merevlemez nem volt 
alapvető kellék, és mindenki cserélhető lemezegységeket 
használt. A Unix azonban olyan gépeken fejlődött, amik nem 
éppen hajlékonylemezekről indultak, így ott volt értelme az 
írási műveletek gyorstárazásának is. Ma már nyilván nem a 
DOS példája a követendő. 

A gyorsítótáron kívül fájlrendszerünk hatékonyságát úgy is 
növelhetjük, hogy valahogy csökkentjük a fej mozgását. Ezt 
úgy érhetjük el, hogy azokat a blokkokat, amelyekre nagy 
valószínűséggel egymás után fognak hivatkozni, a lehető leg- 
közelebb helyezzük el egymáshoz (még jobb, ha egy cilinderen 
is vannak). 

Ezt úgy érhetjük el, hogy amikor szabad blokkokat kell foglal- 
nunk, akkor amennyiben lehetséges, mindig egymás utáni 
blokkokat foglaljunk. Bittérképes nyilvántartás esetén, ha az 
egész bittérkép a memóriában helyezkedik el, ez egyszerű 
feladat. Láncolt listásnál sokkalta nehezebb. 

A fájlleírókat használó fájlrendszerek esetében azonban egy 
másik gond is felmerül: még a legkisebb állomány eléréséhez 
is legalább két blokkot be kell olvasni. Amennyiben a fájlleírók 
a lemez elején lennének, a fejet általában a lemez közepére 
kellenne pozícionálni. Javíthat a helyzeten, ha a fájlleírókat 

a lemez közepén helyezzük el, így átlagosan nézve a fej csak 
feleannyi távot fog befutni. 


Fájlrendszer-ellenőrzés 

Minden igyekezet ellenére is előfordulhatnak olyan szerencsét- 
len esetek, amikor úgy hal meg a rendszerünk, hogy még 
maradt kiíratlan módosított blokk. Ha ez a blokk netán egy 
fájlleírót vagy egyéb fontos adatot tartalmazott a fájlrendszer- 
ről, akkor a fájlrendszer sérül, más néven inkonzisztens 
állapotba kerül. 

Az inkonzisztens fájlrendszer nem biztos, hogy használha- 
tatlan, lehetséges, hogy csak egy-egy blokk válik elérhe- 
tetlenné stb. Mindenesetre nem jó dolog, ha a fájlrendszer 
nem egészséges, ezért érdemes valamiféle inkonzisztencia- 
ellenőrző és -javító programot futtatni. A továbbiakban 

most egy ilyen alkalmazás működésének a rejtelmeibe 
pillantunk bele. 

Az inkonzisztencia ellenőrzését végezhetjük blokkonként és 
fájlonként is. Először nézzük a blokkonkénti ellenőrzést! 
Először is minden blokkhoz két számlálót rendelünk: az egyik- 
ben azt számoljuk, hogy az adott blokk hány fájlban fordul elő, 
a másikban pedig, hogy hányszor fordul elő a szabadlistában. 
Ezután végigmegyünk az összes fájlleírón, ennek alapján az 
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összes blokkot, amelyhez fájl tartozik, elérhetjük. E blokkok 
számlálóját mindig megnöveljük eggyel. Ha ez kész, akkor 
jöhet a szabadlista (illetve a bittérkép) végigpásztázása. Ha egy 
blokk előfordul, akkor annak a másik számlálóját kell növelni. 
Ezzel a vizsgálat be is fejeződött: fájlrendszerünk akkor és csak 
akkor lehet összefüggő, ha az összes blokk számlálóinak értéke 
közül pontosan csak az egyik 1. 


[farsal sségi falú 1106 1 





now checking the folloming areas of drive C: 


4 Pause 





Ez logikus, mivel ha mindkét számláló nulla lenne, akkor 
az olyan, mintha az a blokk nem is létezne. Ebben az 
esetben hiányzó blokkról beszélünk. Ez nem jelent súlyos 
veszélyt a fájlrendszerre nézve, de kapacitásveszteséggel 
jár. A hiba szerencsére könnyedén javítható, csupán fel 
kell venni a szabadlistába. Az sem túlzottan egészséges, 

ha egy blokk kétszer szerepel a szabadlistában. Ebben az 
esetben a megoldás kulcsa az, hogy elölről építjük az egész 
szabadlistát, ügyelve arra, hogy az adott blokk már csak 
egyszer kerüljön bele. 

Érdekesebb a helyzet akkor, ha azt kapjuk eredményül, 
hogy egy blokk több fájlhoz is tartozik. Ez nagyon veszélyes 
lehet a fájlrendszerre nézve, mivel ha letörlünk egy olyan 
állományt, amelyikben ez a blokk szerepel, akkor a blokk 
egyszerre lesz szabad is, meg foglalt is. Ha a másik ilyen 
állományt is letöröljük, akkor a blokk , kétszeresen" lesz 
szabad. Ezt a hibát ezért mindenképpen javítanunk kell. 

A bevált módszer a következő: foglalunk egy új blokkot, 
ami a sérült blokk tartalmával töltünk fel. Ezután a sérült 
blokkot kiszedjük a második fájlból, a helyére pedig betesz- 
szük az újonnan létrehozott blokkot. Valamelyik állomány 
tartalma minden bizonnyal sérülni fog, de nézzük a jó 


oldalát: fájlrendszerünk következetessége helyreállt. 

A fájlok szerinti összefüggés ellenőrzésekor blokkok helyett 
az állományokon megyünk végig. Pontosabban belenézünk 
az összes könyvtárba, és megszámoljuk, hogy egy adott 
fájlleíróhoz hány állomány tartozik. (Minden fájlleíró tartal- 
maz egy kapcsolatszámláló nevű változót, ami megmondja, 
pontosan hány állomány is tartozik hozzá.) Ezután belenéz 
a fájlleíróba is. Ha ott több, netán kevesebb állomány szere- 
pelne, mint amennyi a könyvtárakon végzett ellenőrzés 
eredménye, akkor baj van. 

Ha a fájlleíró kapcsolatszámlálójának értéke nagyobb, 

mint amennyit mi számoltunk, az még a jobbik eset. Ha 
nem javítjuk, annyi történhet, hogy ha az összes olyan 
állományt kitöröljük, amelyik az adott fájlleíróhoz tartozik, 
akkor a fájlleíró maga nem szabadul fel, mivel a számláló 
értéke biztosan nagyobb lesz nullánál. Iehát helypazarlás 
áll fenn. Mindenesetre a kapcsolatszámláló csökkentésével 
a gond megoldható. 

A legizgalmasabb azonban az az eset, amikor több állományt 
számoltunk össze, mint amennyiről a fájlleíró , tud". Ilyenkor 
ugyanis adatvesztéssel is számolnunk kell. Miért is? legyük fel, 
hogy letöröljük az egyik állományt. Ha a fájlleíró számlálója 
egy volt, akkor most nulla lesz, és felszabadul a fájlleírót 
tartalmazó blokk. A másik állományt és annak tartalmát soha 
többé nem fogjuk tudni elérni. Azért a helyzet korántsem ilyen 
súlyos, egyszerűen csak állítsuk a kapcsolatszámláló értékét 
annyira, amennyit mi számoltunk. 

A mostani ellenőrzőprogramok e két módszert (a blokk 

és az állomány szerinti ellenőrzést) együtt használják, 
hatékonysági okból kifolyólag a két folyamat egymástól el 
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sem választható. Ennek köszönhetően a fájlleírót csak 
egyszer kell átnyálazni. 

Ezek a hibák, amelyek veszélyeztethetik a fájlrendszer össze- 
függőségét, általában mindig a felhasználótól független esemé- 
nyek miatt következnek be, például rendszerösszeomlás, 
áramszünet miatt. Igaz, akad egy kivétel: a rendszer helytelen 
leállítása. De most már tudjuk, mivel járhat egy ilyen csele- 
kedet, így remélhetőleg senki sem fog ilyesmire vetemedni. 
Nem számoltunk még azonban a felhasználó által okozott 
hibákról sem, ilyen például állományok véletlen letörlése, vagy 
a törlés parancs helytelen használata. Az ilyenek miatt nem 
lesz a fájlrendszer inkonzisztens, csak a felhasználó adatai 
tűnhetnek el, de ez elég ok arra, hogy létezzen valamilyen 
védelmi módszer. Nem minden fájlrendszer tartalmaz ilyet, 

és ha tartalmaz is, mind-mind különböző módon. Az MS-DOS 
például nem végezte el a tényleges törlést (azaz a blokkok 
felszabadítását) egészen addig, amíg volt más szabad hely a 
lemezen. Addig a felhasználónak lehetősége volt a megfelelő 
parancs segítségével visszahozni a letörölt állományokat. 

A következő részben a biztonsággal foglalkozunk, pontosabban 
azzal, hogy az operációs rendszerek általában miként védik az 
adatainkat. lermészetesen arról is szót ejtünk, hogy mindezt 
hogyan valósítják meg. 


Garzó András (garzoandOinterware.hu) 


Körülbelül három éve foglalkozik Linux- és más Unix-rendszerekkel. 


Legjobban az operációs rendszerek lelkivilága érdekli, de nyitott 
egyéniség. Kedvenc étele a palacsinta, és van egy Richard nevű 


macskája. Minden észrevételt, megjegyzést, levelet szívesen fogad. 
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Héjprogramozás Linux alatt - az AWK nyelv (5. rész) 


Héjprogramozásról szóló sorozatunk mostani részében 
az AWK sedégprogrammal és szövegfeldolgozó nyelvvel ismerkedünk meg. 


alószínűleg az olvasónak is feltűnt, hogy az előző 
L / részben bemutatott megoldás meglehetősen körül- 

ményes volt. A gondot alapvetően az okozta, hogy 
maga a héj nem rendelkezik olyan szolgáltatással, amivel 
egyszerűen hozzáférhetnénk egy táblázat elemeihez. 
Annak idején talán ez volt az egyik olyan felismerés, ami 
elvezetett az awk segédprogram és szövegfeldolgozó nyelv 
megalkotásához. (A furcsa név a szerzők neveinek kezdő- 
betűből állt össze: Aho, Weinberg, Kernighan.) 
Az awk - bár mérete általában nem haladja meg a néhány száz 
kilobájtot — a korszerű táblázatkezelők gyakorlatilag valameny- 
nyi szolgáltatásával rendelkezik. Az egyetlen — ám sokak szá- 
mára igen lényeges - eltérés az, hogy ennek a programnak 
nincs grafikus felülete, vezérlésére ehelyett egy saját progra- 
mozási nyelv szolgál. 
Az awk nyelve számos ponton erősen hasonlít a C-re. Ennek 
megfelelően összes függvényét, vezérlési szerkezetét és 
egyéb szolgáltatását egyetlen cikkben lehetetlen bemutatni. 
Itt és most csak azokról az alapelvekről és lehetőségekről esik 
majd szó, amelyek a héjprogramokban a leggyakrabban 
felbukkannak. 


Az awk működésének logikája 

Az awk bemenete fájlból és a szabványos bemenetről egyaránt 
érkezhet. A feldolgozást vezérlő programot szintén meg lehet 
adni külön fájlban (ilyenkor a -f kapcsolót kell használnunk), 
de gyakoribb az a megoldás, amikor ezt is rögtön az awk 
kulcsszó után, egyszeres idézőjelek (aposztróf) közé zárva 
adjuk meg. Egy az awk-val kapcsolatos kódrészlet tehát 
sematikusan a következőképpen nézhet ki: 

4 DEMENSU s wz .[ AWk "BEGIN XX 
( utasítások ) 

( főprogram ) 

END ( utasítások )! 


Az első sor végén látható Y (visszaperjel) sorösszefűzést végez, 
vagyis azt jelzi a héj számára, hogy csupán az olvashatóság 
kedvéért írtuk a kódot több sorba. (Ügyeljünk rá, hogy a Vután 
már semmi nem állhat, még szóköz sem!) 

A ,főprogramban" található utasításokat az awk a bemenet 
valamennyi során önműködően végrehajtja, vagyis a program 
eleve tartalmaz egy rejtett (implicit) ciklust. (Emlékezzünk rá, 
hogy az előző részben a táblázat sorainak végigpásztázásához 
nekünk magunknak kellett ciklust írnunk.) 

A BEGIN blokkban szereplő utasítások a sorok feldolgozásának 
megkezdése előtt hajtódnak végre, az END blokk tartalma 
pedig a feldolgozás után fut le. 

És most következzék a lényeg: az awk feldolgozás előtt minden 
sort mezőkre bont. Alapértelmezésként mező az, amit mindkét 
oldalról legalább egy szóköz vagy tabulátor határol. A mezőkre 
a programban a S$1, $2 stb. szimbólumok segítségével egyen- 
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ként lehet hivatkozni. A számozás egytől indul, de létezik a $0 
is, ami a teljes sort jelenti. (Figyelem, ezeknek a szimbólumok- 
nak semmi közük a héjprogram parancssori kapcsolóihoz!) 

Az awk programokban megadhatunk változókat, amelyekre itt 
a héj , szokásaitól" eltérően minden helyzetben egyszerűen a 
nevük leírásával lehet hivatkozni. Az awk az eddig használt 
expr paranccsal szemben lebegőpontos számokkal is képes 
műveleteket végezni, és minden olyan különleges függvényt 
is ismer, amit egy tudományos zsebszámológépen megtalálha- 
tunk. Az eredmények kiíratására a print parancsot 
használhatjuk. 


A sorok összegzése 
Ennyi bevezető után lássuk, miként valósítható meg az awk 
segítségével egy táblázat sorait összegző függvény: 


sorosszeg ( ) 
( 
cat S$1 I awk NM 
"( osszeg-0 
for(1-1;1c-NF;1--) 
print osszegj)"! 


o0s88Zegt-Si 
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A cat parancs utáni $1 szimbólum most is a függvény (és nem 
a program) első parancssori értékét jelenti, a 3. sor végén pedig 
az előbb említett, az olvashatóságot megkönnyítő sorösszefűző 
karakter látható. A pillanatnyi sor mezőin végig haladó for 
ciklus akár a C-program része is lehetne. A C nyelvet nem is- 
merők kedvéért talán érdemes megemlíteni, hogy az 1--- szim- 
bólum az 1-i--1 művelet , rövidített" megfelelője, a --— műve- 
leti jel (operator) pedig az osszeg-osszeg4S$i művelet 
leírását teszi egyszerűbbé. Mindkét megoldás a C nyelvből ered. 
A ciklus leállási feltételében szereplő NF az awk egyik önmű- 
ködően frissülő belső változója, ami a feldolgozás alatt álló sor 
mezőinek számát tartalmazza. Gyakran szükséges ezenkívül 
még az NR belső változó, ez a pillanatnyi sor sorszáma (a szá- 
mozás egytől indul). 


Az oszlopok összeadása 

A sorok összegzésénél nem volt szükség az awk programon 
kívüli ciklusra, mivel a végigpásztázásuk önműködő. Az osz- 
lopok esetében ilyen automatizmus már nincs, így itt két cik- 
lusra lesz szükségünk. A megoldás azonban még így is rövidebb 
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és áttekinthetőbb lesz, mint az előző részben bemutatott. 


1: oszloposszeg() 

as. a 

3: oszlopszam- head -1 S1 I wc -w 
4 tel 

5 while [ Si -le Soszlopszam ] 

6 do 


7 cat S1 ] awk -v oszlop-Si NM 
8 : "BEGIN ( osszeg-0 ) 
9 : ( osszegt-Soszlop ) 
10 : END ( print osszeg )! 
11: 1- expr Si 11 
12 : done 
13: ) 


A 3. sorban kiderítjük, hogy hány oszlopból áll a táblázat. 


Ehhez a head segítségével kiemelt első sorban megszámoljuk a 
szavakat. A következő érdekes momentum a 7. sorban látható. 


Itt az awk -v kapcsolója segítségével kívülről állítjuk be az 
oszlop nevű awk változó értékét. Ez fogja megmutatni, hogy 
éppen hányadik oszlop összegzésénél tartunk. A szabványos 
ki- és bemeneten kívül a -v kapcsoló szolgáltatja az egyetlen 
kapcsolattartási lehetőséget a héjprogram és az awk program 
között. Ezzel a módszerrel természetesen több változó 
tartalmát is beállíthatjuk, a -v kapcsolót azonban minden 
értékadásnál meg kell adni. 

Magának az osszeg változónak a nullázása most a BEGIN 
blokkba került, hiszen ezt a műveletet csak egyszer akarjuk el- 


végezni. Hasonló okok miatt került az eredmény kiíratása az END 


blokkba. Maga a főprogram csupán egy összegzést tartalmaz. 
A kész héjprogram most is a fenti részek egyszerű összemá- 
solásával állítható elő, a parancssori kapcsolók kezeléséhez 
pedig ugyanazt az egyszerű case szerkezetet használhatjuk, 
mint a sorozat előző részében. 


Szépészet awk-val 

Befejezésül bemutatom az awk használatának egy másik 
lehetőségét is. Biztosan az olvasónak is feltűnt már, hogy 
milyen , rendszerető módon" vannak sorszámozva a 
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et 


sorozatban megjelent kódszövegek. Egy igazi Linux- 
felhasználónak természetesen eszébe sem jut, hogy ilyesmit 
kézzel tegyen meg - helyette megírja a következő nyúlfarknyi 


programot: 

1: t!/bin/sh 

2: cat Si I awk NM 

3: "( 1£ (NRc10) 

4 : ( print " "NR": " SO ) 
Bs else 

6 : forint NR": " §$0]) 

7: H)" 


Mint korábban említettem, az NR belső változó, amelynek a 
tartalma az éppen feldolgozott sor sorszáma, vagyis éppen az, 
amire nekünk szükségünk van. 

Ha azt akarjuk, hogy az egy- és kétjegyű sorszámok utáni 
kettőspontok szépen egymás alatt sorakozzanak, az egyjegyű- 
ek elé egy-egy szóközt is be kell illesztenünk. Éppen ezt teszi a 
fenti döntési szerkezet igaz ága. (Figyeljük meg, hogy awk-ban 
a karakterláncok összefűzéséhez elegendő egyszerűen 
megszakítás nélkül egymás mellé írni őket.) 

Van ebben a megoldásban egy kis tökéletlenség: akkor is 
beljebb tolja az egyjegyű sorszámokat, ha nincsenek 
kétjegyűek. Ennek megoldását az olvasóra bízom. 







Büki András (buki(ovuk.chem.elte.hu) 
Körülbelül kilenc éve dolgozik Linux 
operációs rendszerrel. Állandó szerzőtársa 
Prof. Dr. H. V. Kuksinak, akivel a Duna vagy a 
Tisza partján szoktak az élet és a tudomány 
viselt dolgairól töprengeni. 
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Az XML és a Perl (1. rész) 


E 


Az egyik legáltalánosabb adattárolási módszer alkalmazása 
a legnépszerűbb programozási nyelvek egyikével. 


a programozási nyelvről beszélünk, egy olyan, a számí- 
Hi tógép által értelmezhető szövegre gondolunk, ami egy 

alkalmazást ír le. Erre jó példa a Perl. Ugyanakkor meg- 
lepően sűrűn előfordulhat az is, hogy az adatunk válik olyan bo- 
nyolulttá, hogy külön nyelvre van szükségünk a leírásához. Igen 
egyszerű adatnyelvek is léteznek már. Először ezekről esik szó. 


Adatnyelvek 

Feltételezem, hogy némi gyakorlatra tettél szert a Perlben, és 
adatforrásként használtál már vesszővel elválasztott mezőket 
tartalmazó sorokat (más néven rekordokat) magába foglaló 
állományt. Léteznek ennél bonyolultabb nyelvek is, mint az, 
amelyikkel a Makefi1e-okban találkoztál. Ez egy program 
lefordításához szükséges adatokat tartalmazza. A szövegalapú 
adattárolás csúcsát bizonyos értelemben a Sendmail beállító- 
állománya jelenti. Ha eddig nem találkoztál vele, örülj neki, 
hogy megúsztad. 


Az SGML 


Hozzávetőlegesen harminc évvel ezelőtt vetődött fel egy 
teljesen általános adatnyelv létrehozásának az ötlete. Hamar 
be kellett látni azonban, hogy lehetetlen lenne az adattárolás 
területén minden elképzelhető célra egyetlen nyelvet felkészí- 
teni. Így az utóbbi feladattal küzdő csoport új célt tűzött ki 
magának. Egy olyan metanyelvet kívántak létrehozni, amellyel 
már könnyedén készíteni lehet egy jelölőnyelvet egy valóságos 
dokumentumhoz. Ennek a törekvésnek az eredménye az 
SGML (Standard Generalized Markup Language), amely 
1986-ban vált nemzetközi szabvánnyá. Az SGML neve egy 
picit megtévesztő, hiszen ez önmagában nem egy jelölőnyelv 
(markup language), hanem egy metanyelv jelölőnyelvek meg- 
határozásához. Minden ilyen jelölőnyelvet SGML-alkalmazás- 
nak hívunk, ami ismét megtévesztő lehet azoknak, akik az 
alkalmazás szót csupán egy program szinonimájaként ismerik. 
A legtöbb SGML-alkalmazás nagyon sokáig ismeretlen volt az 
amerikai katonaságon és az egyes közhivatalok berkein kívül. 
A 90-es évek elején azonban színre lépett egy jelölőnyelv, amire 
a média is hamar rákapott: ez volt a HIML (Hyperlext Markup 
Language). Minden SGML-alkalmazás hasonlít a HIML-re 
annyiban, hogy egyetlen elemből áll, ami elemeket tartalmaz, 

s ezek további elemekből, illetve egyszerű szövegből állnak. 
Az elemek elejét és a végét kezdő- és zárócímkék jelentik, 
amelyek relációjelek között szerepelnek. Nagy vonalakban így 
fest egy SGML-dokumentum. Az SGML nagyon tág fogalom, 
és írásmódja számos dolgot engedélyez, ezért olyan nehéz 
SGML értelmezőt írni. Egy SGML-értelmező ráadásul addig 
nem is tud megfelelően értelmezni egy dokumentumot, amíg 
nincs meghatározva a jelölőnyelv nyelvtana, a DID (Docu- 
ment Iype Definition) -— de erről majd később ejtünk szót. 


Az XML 


Az SGML azt mutatta, hogy egy hozzá hasonló nyelv tökéletes 
választás lehetne a különböző programok közötti adatcsere 
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megoldására. Hamar be kellett látni, hogy a hasonlónak 
egyben egyszerűbbnek is kell lennie. 1996-ban a World Wide 
Web Consortium (W3C) megbízott egy csoportot az SGML 
kistestvérének a kidolgozásával, ami elég egyszerű ahhoz, 
hogy adatcseréhez lehessen használni, különösképpen webes 
alkalmazások esetében. Ez volt az XML (eXtensible Markup 
Language). 1998 februárjában jelent meg az XML-ajánlás, amit 
a 5 http:/www.w3.org/IR/REC-xml címen olvashatsz el. 


Az XML működése 

Minden XML-dokumentum egy elhagyható bevezetőből 
(prolog) és egy ezt követő elemből, a gyökérelemből (root 
element) áll. Minden elem elejét egy kezdőcímke jelöli, ami egy 
kisebb jelből ( €), egy névből, egy elhagyható tulajdonság-érték 
párokból álló listából, és egy záró nagyobb jelből (- ) áll. Minden 
elem végét zárócímke jelöli, ami hasonlít a kezdőcímkére, de 

a kisebb jel után közvetlenül egy perjel (/) található, és nincs 
tulajdonság-érték listája. Az üres elemek azok, amelyek nem 
tartalmaznak további elemeket, illetve szöveget. Ezeket olyan 
módon írhatjuk le rövidebben, hogy elhagyjuk a zárócímkét, 
ugyanakkor a kezdőcímkében a nagyobb jel elé egy perjelet 
szúrunk be. Egy nagyon egyszerű XML-dokumentum így fest: 
czdokumentum:sSzia, vilag!-c/dokumentumz 
Szándékosan használtam a magyar dokumentum szót, hiszen 

a címke nevét én határozom meg. Ebben a példában mindössze 
egyetlen gyökérelemünk létezik, a dokumentum, és csak egy- 
szerű szöveget tartalmaz. Nincsenek tulajdonságai (attributum) 
— adjunk neki egyet! 

czdokumentum ti1pus-"pelda":Szia, vilag! 
c/dokumentumz 


Most már dokumentum elemünknek van egy tulajdonsága, 

a tipus, ennek értéke a "pelda". Az XML-ben minden 
értéket idézőjelek közé kell tenni, és minden tulajdonságnak 
kötelező értéket kell adni. Az érték nélküli tulajdonságok 
elfogadottak az olyan SGML-alkalmazásokban, mint a HIML, 
de az XML-ben nem. 

Az XML-t létrehozó csapat ezt annak érdekében határozta 
meg, hogy az XML-értelmezők egyszerűbbek és ezáltal 
gyorsabbak legyenek. 

Az eddigi példákban dokumentumaink csak egyetlen elemből 
álltak, és az is csupán szöveget tartalmazott (hivatalosabban 
karaktereket). Az XML igazi ereje azonban strukturáltságában 
rejlik: szövegen kívül az elemek további elemeket is tartal- 
mazhatnak. Lássunk erre is egy példát! 


ckozerts 
cCcsoport nev-"zoldseg"5s 
caruskrumplic/arusz 
€a/csoports 


cCcsoport nev-"gyumolcs"z 
carusalmac/arus 
caruskortec/arusz 
€a/csoports 
€c/kozerts 


Itt a gyökérelemünk a kozert nevet kapta. Ez két csoport 
nevű elemből áll, ezek nev tulajdonsággal rendelkeznek. 

Az egyik a zoldseg, míg a másik a gyumolcs értéket kapta. 
Ezeken belül aru elemeket találunk, a fenti két típusnak meg- 
felelően elrendezve. Az XML szépségét mutatja, hogy ezt a szer- 
kezetet többféleképpen is feldolgozhatjuk, ahogyan a sorozat 
következő részeiben bőven láthatunk rá példát. A DOM felépítés 
például egy faelrendezésben tálalja számunkra az adatokat. 
Mivel a cikksorozat az XML és a Perl kapcsolatával foglalkozik, 
ez a bevezető nem szolgálhat minden részletre kiterjedő 
leírással az XML-t illetően. Ha további tájékoztatásra lenne 
szükséged, látogass el a 5 http://www.xml.com oldalra. 


Mi nem az XML? 


Számos félreértésből származó tévhit kering az XML -ről, és 
arról, hogy miért is hozták létre. Az XML azonban 
e nema HIML helyettesítője. Az XML egy metanyelv, míg 
a HIML tényleges nyelv, amit az SGML metanyelvvel hatá- 
roztak meg. A HIML-nek előre rögzített elemei vannak, 
az XML-alkalmazások elemeit az alkotóik határozzák meg. 
Ugyanakkor a HIML-t az XML szabályai alapján is írhat- 
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juk, és elképzelhető, hogy a HIML következő változata egy 
XML-alkalmazásként fog megjelenni. 

nem olyan nyelv, ami otthoni kiadványszerkesztést 

tesz lehetővé a weben. 

nem a relációs adatbázisok helyettesítője. Kis adatmennyi- 
ség esetén használhatunk XML -alkalmazást relációs adat- 
bázist használó programok közötti adatcserére, de nem túl 
megfontolt döntés egy egész adatbázist így tárolni. 

nem egy mindenre használható svájcibicska tetszőleges 
nyelvek létrehozásához. 


Létre lehetne hozni egy egész programozási nyelvet XML-ben, 
de ronda lenne és teljes mértékben rugalmatlan. Az XML olyan 
adatok ábrázolására alkalmazható jól, amelyek természetüknél 
fogva hierarchikusak, illetve bizonyos matematikai modellek 
esetében (mint a gráfok). 

Szerintem az XML érdekes megközelítése az adattárolásnak, 
és megér egy próbát. Mindent ki kell próbálni, és ha már 
használtad, eldöntheted, hogy tetszett-e vagy sem. 


Fülöp Balázs (xutofreemail.hu) 

18 éves, Imádja a Túró Rudit, a Deblan Linuxot 
és a teheneket. Kedvenc írója Slawomir Mrollek. 
leginkább a számítógépes hálózatok biztonsága 
érdekli. A BME VIK műszaki informatikus 

szak hallgatója. 
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CIMIF-tiípusok 


Egy tartalomkezelő csak testreszabás után használható igazán. 
Kezdjük munkánkat egy olyannal, ami elég hatékony ahhoz, 
hogy éppen úgy működjön, mint a szervezetünk. 


z előző hónapokban általánosságban foglalkoztunk 
AA a tartalomkezelő rendszerekkel (CM5), majd külön 

kiemeltük a Zope tartalomkezelő keretrendszerét 
(CMF). A Zope CME olyan eszközt ad a fejlesztők kezébe, 
amellyel megalkothatják a saját tartalomkezelő rendszerüket. 
lermészetesen az, aki már dolgozott CMS-rendszerrel, tudja, 
hogy felhasználás előtt még a kereskedelmi változatok legtöbb- 
jét is alaposan át kell szabni és újra kell dolgozni. A Zope nem- 
csak egyszerűen az alapprogram árát csökkenti, de gazdag 
környezetet is kínál, amelyben könnyedén fejleszthetjük és 
ízlésünkhöz igazíthatjuk a CMS-t. 
A CMF-oldalak létrehozása során (az oldal gazdájaként) doku- 
mentumokat adhatunk a rendszerhez, illetve módosíthatunk 
és törölhetünk. Kattintsunk a könyvtártartalom hivatkozásra, 
majd bökjünk a New... gombra, és válasszuk ki, hogy milyen 
típusú dokumentumot szeretnénk, illetve milyen azonosítóval 
rendelkezzen, majd kattintsunk az Add gombra. Gépeljük be 
a segédadatokat (ez a cím, a leírás, a téma és a tartalomtípus), 
kattintsunk a ChangeG Edit gombra, gépeljünk be valami tartal- 
mat, és már kész is vagyunk. 
Igaz ugyan, hogy a már meglévő tartalomtípusok egy-egy egy- 
szerű oldal esetében elegendőnek bizonyulhatnak, a kifino- 
multabb oldalakhoz általában egyedi változatokra van szükség: 
a saját típusokra. A CMF pontosan ennek a lehetőségét kínálja 
fel. Ebben a hónapban a CMF-be illeszthető típusokkal foglal- 
kozunk, megtudhatjuk, hogy miképpen dolgozzunk velük, 
viselkedését hogyan szabjuk az igényeinkhez, milyen módon 
telepítsünk újabb elemeket, vagy akár hogyan készítsünk saját 
tartalmat kezelő egyedi típusokat. 


A CMF-típusok 
Az új típusok létrehozásának legegyszerűbb módja, ha a CMF 


beépített, webalapú típuskiterjesztés rendszerét használjuk. 
Ennek segítségével olyan új típusokat hozhatunk létre, ame- 
lyek tagfüggvényeiket, tulajdonságaikat, műveleteiket, megje- 
lenítő sablonjaikat és ikonjaikat megoszthatják a többi típussal. 
Amikor a webalapú kiterjesztésrendszerrel új típust hozunk 
létre, az elemek bármelyikét megváltoztathatjuk, kivéve a tag- 
függvényeket és a tulajdonságokat (properties). Más szavakkal, 
újonnan létrehozott típusunk akár egészen más kinézettel is 
rendelkezhet, mint a szülőtípusa, a viselkedése azonban 
továbbra is nagyon hasonló lesz. 

A példa kedvéért vegyük a types eszközként ismert elemet, 
amihez a CMF-oldalunk kezelőfelületének portal types ele- 
mére kattintva juthatunk el. Ha még nem adtunk meg CMF- 
oldalt a Zope alatt, könnyedén készíthetünk egyet a webalapú 
Zope-kezelőfelület jobb felső sarkában található Add... menü 
CMEF Site pontjának kiválasztásával. Miután elkészítettük az 
oldalt, a kezelőfelületből a hozzátartozó ikonra kattintva jó 
néhány, csavarkulcsra emlékeztető ikonnal ellátott különböző 
beállításeszközt fogunk találni. 
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Amikor első ízben lépünk be a types 

(típusok) eszközbe, megfigyelhetjük a jeles 

megadott CMF-típusokat, többek közt a folders (mappák), 

documents (dokumentumok), news items (hírelemek), links 

(hivatkozások) és topics (témák) típusait. A kiválasztott típus 

nevére kattintva megnézhetjük, illetve megváltoztathatjuk a 

típusokhoz tartozó tulajdonságokat és műveleteket. Ha például 

a File tartalomtípus működését meg szeretnénk változtatni, 

kattintsunk a File-ra. Az oldal tetején új fülkészlet jelenik meg, 

amelyek közül csak a properties (alapértelmezett tulajdonsá- 
gok) és az actions (műveletek) lesz az, ami nem része a hagyo- 

mányos Zope-készletnek. Igazság szerint a tulajdonságok fül a 

szabványos Zope-fülek közt is megtalálható, de a CMF-típusok 

számos szokatlan tulajdonságnévvel is bírnak. 

A megszokott szabványtulajdonságokon túl minden típus 

néhány, a működését befolyásoló egyéb tulajdonsággal is 

rendelkezik: 

e — Icon: karaktersorozat, ami azt írja le, hogy az adott típushoz 
milyen ikon jelenjen meg. 

e Product metatype: a Zope-termék metanevét adhatjuk meg 
itt. A metaneveket az Add... menüpontban a Zope-kezelő- 
felületén (Management Interface) használjuk. A CMF 
hasonló Add... menüjében úgyszintén ezt a nevet találjuk. 

e Product name: azt a Zope-terméket jelöli meg, amelyikben 
a CMF-típust meghatároztuk. Minthogy a File és a News 
elemtípusok már az eredeti CMF-telepítésben is benne 
vannak, itt a CMFDefault termék neve szerepel. Ami igaz is, 
hiszen ha belenézünk a /lib/python/products/CMFDefault 
könyvtárba, amely, CMF 1.3-as változat alatt a CMF-1.3/ 
CMFDefault könyvtárra mutató közvetett hivatkozás, 
megtalálhatjuk a tartalomtípusokat meghatározó File.py 
és a NewsItem.py Python-modulokat. Ha kíváncsiak 
vagyunk, hogyan állíthatjuk be a tulajdonságok alapérté- 
keit, nézzük meg a factory type information 
változót bármelyik CMF-típus akármelyik moduljában. 

e Product factory method: megadja azt a tagfüggvényt, 
amelyet a CMF a típus új példányainak a létrehozásához 
hív majd meg. 

e Filter content types és Allowed content types: ez a két 
bejegyzés ugyan két különálló tulajdonság, de együvé 
tartoznak. Mindkét tulajdonság valamennyi CMF-típusban 
megtalálható, kizárólag a mappa stílusú elemekre vonat- 
koznak. Ilyen például a Folders vagy a Topics. Az első, a 
Filter content types kétértékű változó, amely az 
Allowed content types érvényességét kapcsolja ki-be. 
A második, az Allow content types változó azt mutatja 
meg, hogy milyen altípusok kerülhetnek az adott típusba. 
lehát például, ha egy olyan könyvtárat szeretnénk létre- 
hozni, ami kizárólag hírelemeket tartalmazhat, ezt a yes-re 
való kattintással könnyedén megtehetjük, majd megmu- 
tatva, hogy mely típusokat engedélyezzük. 





Új típus létrehozása 

Új CMF-típusokat úgy hozhatunk létre a legkönnyebben, ha 
egy már létező típusra alapozva a webalapú CMF-típuskészítő 
eszközt használjuk. Ez a módszer ugyan nem engedi meg, 
hogy a típussal kapcsolatos mezőket vagy tagfüggvényeket 
megváltoztassuk, viszont lehetővé teszi, hogy szabadon állít- 
hassuk be a típus műveleteivel kapcsolatos engedélyeket, meg- 
adjuk, hogy a típus megvitatható-e, sőt még az adattípus 
megjelenítésének a módját is megengedi. 

Például lépjünk be a portal types eszközbe, és a jobb felső 
sarokban található Select type to add... menüpontból válasszuk 
a gyárilag meglévő típusadatot. Itt két adatot kell majd meg- 
adnunk: az új típus nevét vagy azonosítóját, illetve azt a már 
létező típust, amelyre alapozni akarjuk. Az ATFDocument 
típust fogjuk létrehozni, amit értelemszerűen a Document nevű 
CMF alapértelmezett típusra fogunk alapozni. 

Miután az új típust létrehoztuk, az összes típuslistában látható 
és elérhető lesz, ideértve a típuseszközöket és a tartalomnéze- 
tet, amelyben a típusból új példányokat készíthetünk. lulaj- 
donképpen bárki, aki rendszergazdai jogosultságokkal rendel- 
kezik az oldalon, mostantól megtalálhatja az új ATFDocument 
típust abban a menüben, ahonnan az újonnan létrehozandó új 
típusokat is kiválaszthatja. 

De mi értelme van ennek, ha egyszer az ATFDocument és a 
Document teljesen egyforma? Nos, valójában nem teljesen egy- 
formák, inkább csak azonos tagfüggvényeken és általános 
osztálymeghatározásokon osztoznak. A típus egyéb jellemzői, 
mint például a tulajdonságok, az engedélyek és a bőrök (skins) 
alapértelmezés szerint azonosak ugyan a Document beállításai- 
val, de bármikor teljesen megváltoztathatják a kinézetet. Így 
például, ha azt szeretnénk, hogy a Document fehér alapon 
feketével jelenjen meg, vitafórum nélkül, az ATFDocument 
viszont gesztenye alapon sárga színnel és vitafórummal, ezt 
ezzel a módszerrel minden további nélkül, néhány kattintással 
kialakíthatjuk. Azután, amikor a későbbiek során CMF-rend- 
szerünket fejlesztjük, az ATFDocument típus a Document 
típussal együtt önműködően frissülni fog. 


A színfalak mögött 

Könnyen előfordulhat azonban, hogy olyan típust szeretnénk, 
amely a meglévő típusoktól teljesen eltérő mezőkkel vagy visel- 
kedéssel bír. Erre is létezik néhány lehetőség, ezek közül a leg- 
rugalmasabb (s egyben legnagyobb kihívást jelentő, és legsilá- 
nyabbul dokumentált) módszer a CMF-szabályoknak megfelelő 
új Zope-termék létrehozása. Minden Python-csomagnak a 
csomag gyökérkönyvtárában tartalmaznia kellegy . init .py 
állományt. Ez az állomány akár üres is lehet, de itt helyezhetjük 
el azokat az utasításokat, amelyek a modul első memóriába 
töltése során elindulnak. A termékek esetében maga az osztály 
az initialize() tagfüggvény segítségévelaz  init .py 
belsejében jegyzi be magát a Zope rendszerébe, ami egyetlen, 
általában context-nek nevezett értéket fogad. A lecsupaszított 
Zope-termék tehát egyetlen . init .py állományból áll, ami a 
következő misztikus MyProduct-termékhez hasonlít: 


import MyProduct 
def initialize(context) : 
context .registerClass( 
MyProduct . MyProduct, 
constructorsz 
s (MyProduct .manage addMyProductForm, 
MyProduct . manage addMyProduct) 
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A Zope induláskor végignézi a termékeket és a megfelelő 
összefüggésekkel (contex) meghívja az initialize() 
tagfüggvényeket. Az összefüggések a Zope szerzeményező 
rendszerének a részei, ahol az objektumok tulajdonságait a 
rendszerben elfoglalt helyük legalább annyira meghatározza, 
mint az eredeti osztálymeghatározás. A fenti példában a 
MyProduct két létrehozóval (constructor) jegyzi be magát: ez a 
manage addMyProductFormés a manage addMyProduct. 
A CMF-típusnak nemcsak a Zope, hanem a CME rendszerébe is 
be kell jegyeznie magát, már amennyiben meg akar jelenni 

a különféle CMF-eszközök között. lermékünk initialize() 
tagfüggvényének ezért a CMF-hez tartozó bejegyzési művele- 
teket is tartalmaznia kell, azaza — init .py programnak modu- 
lokat kell importálnia a CMF-ből. Iovábbá minden CMF-típusnak 
be kell jegyeznie magát a Products . CMFCore.uti1ls egyik 
CMF vonatkozású alaphelyzetbe állító eljárásával. Például a 
CMF-be épített CMFDefault  init .py programja első lépésként 
megadja azokat az osztályokat, amelyeket az elkövetkezendők- 
ben be fog jegyezni: 
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contentClasses - ( Document .Document 
, File.File 
, image.lmage 
, Link.Link 
, Favorite.Favorite 
, Newsltem.Newsiltem 
, SkinnedFolder. 
s SkinnedFolder 


Majd valamennyi osztályhoz megad egy létrehozót: 


contentConstructors - ( Document.addDocument 
, File.addFile 
, Image.addílmage 
, Link.addlink 
, Favorite.addFavorite 
, Newsiltem.addNewsitem 
, SkinnedFolder.addSkinnedFolder 


Természetesen minden osztály saját egyedi eszközzel 
rendelkezhet: 


tools - ( DiscussionTool.DiscussionTool 
, MembershipTool.MembershipTool 
, RegistrationTool.RegistrationTool 
, PropertiesTool.PropertiesTool 
, URLTool.URLTool 
, MetadataTool.MetadataTool 
, SyndicationTool.SyndicationTool 


Bizászzást 


Végül a csomag initialize() tagfüggvénye, amit egy kicsit 
lerövidítve adunk közre, eszközök esetében a 
utils.Toollnit ( ) , tartalom esetében pedig a ContentInit 
eljárással bejegyzi az osztályokat. Ezután a visszakapott értékkel 
meghívja az initialize(context ) függvényt, ezáltal 
jegyezve be az új terméket a Zope rendszerébe: 


def initialize( context ): 


utils.Toollnit( CMEDefault Tool", 
stools-tools, 
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product name- "CMFDefault ", 
1con- tool.gif ", 
) initialize( context ) 


utils.ContentIlnit( "CMFDefault Content" 
, content types-contentClasses 
, permission-AddPortalContent 
, extra constructorsz 
scan entloönsötrüctörs 
, fti-Portal. 
factory type information 
) .initialize( context ) 
context .registerClass(Portal.CMFSite, 
constructors- ( 
sPortal.manage addCMFSiteForm, 
Portal .manage addCMFSite, 
) ) 


Láthatjuk, hogy az initialize ( ) fenti változatának utolsó 
utasítása igen hasonló a MyProduct ( ) példa initialize() 
függvényének utolsó részéhez, ami ékesen bizonyítja, hogy a 
CMF-típusok valójában néhány további kiegészítéssel rendel- 
kező Zope-termékek. 


Erdemes használni a CME rendszert? 

E cikk zárja a Zope mint tartalomkezelői felület körüli vizs- 
gálódásainkat. Körutazásunk a Plone-nal kezdődött, és a 
CMF-rendszerrel, illetve a CMF-típusokkal zárult. Most, hogy 
már egy kicsit részletesebben is megismerhettük a CMF 
rendszerét, eldönthetjük, érdemes-e CMS alapú projektekbe 
belekezdenünk. 

Jó hír, hogy CMF igen hatékony és rugalmas rendszer. Egy 
ügyes és hozzáértő fejlesztő kezében lehetővé teszi, hogy saját 
CMS rendszert hozzunk létre a piacon jelenleg elérhető üzleti 
rendszereknél jóval olcsóbban, ugyanakkor nagyobb rugalmas- 
sággal. Minthogy a rendszer teljes egészében a gyors fejlesz- 
tésekhez szánt Zope-ra épül, az új típusok létrehozása, a 
sablonok módosítása és az új szolgáltatások fejlesztése igen 
egyszerű és gyors. 

Ugyanakkor a CME akárcsak a legtöbb nyílt forrású program, 
iszonyú hiányt szenved naprakész, használható leírások 
terén. Bizonyos vagyok benne, hogy a Plone CMS rendsze- 
rének sikere nagyrészben a Plone-hoz tartozó kiváló leírásnak 
köszönhető. 

lehát amennyiben használni szeretnénk a CMF-et, készüljünk 
fel egy komoly adag Python-kód átrágására, nem kevés kísérle- 


tezgetésre és más CMF-fejlesztők segítségének igénybevételére. 


Figyelembe véve a CMF központi szerepét a Zope világában, 
véleményem szerint a CMF-leírások minősége és mennyisége 
folyamatosan javulni fog. Amíg azonban ez az idő el nem jön, 
a CMF-fel való munka sok-sok türelmet, forráskódböngészést, 
próbálkozást és hibajavítást igényel. 

A CMF rendszert jelenlegi állapotában — a legnagyobb 

és legösszetettebb tartalomkezelő rendszerek kivételével 

— egy kicsit haboznék bármi másra felhasználni. 

Ahogy mondják, a CMF rugalmassága és hatékonysága 
pontosan ebben a méretarányban mutatkozhat meg a 
leginkább. Röviden: amennyire a CMF nem megfelelő 

a kisebb munkákhoz, valószínűleg épp annyira jól műkö- 
dik a nagyoknál. Az idő múlásával várhatóan egyre jelen- 
tősebb szerepet tölt majd be a nyílt forrású tartalomkezelés- 
ben, keretrendszert biztosítva egy saját CMS programrend- 
szer gyors kifejlesztéséhez. 
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Osszefoglalás 

A Zope CMF saját CMS-készítéshez használható lenyűgöző 
keretrendszer. Kétségem sincs afelől, hogy a CMF alatt könnye- 
dén lehet CMS rendszert készíteni, ráadásul lényegesen keve- 
sebb költséggel és erőfeszítéssel, mint amennyit egy teljes 
értékű üzleti megoldás igényelne. Azt mondják, a CMF ideje 
még nem érkezett el azok számára, akik nem állnak bensőséges 
viszonyban vele vagy nem szeretnének jelentős időt pazarolni 
a megtanulására. Elgondolkodtató, hogy a CMF a Plone által 
került reflektorfénybe, az a tény pedig, hogy a Zope 3 közel 
vagy teljesen a CMF-fel egybeépítve jelenik majd meg, azt 
sugallja, hogy a Zope Corporation mostantól komoly késztetést 
érez a CMF lenyűgözőbbé és jobban dokumentálttá tételére, 
mint korábban. 

Amennyiben komolyabb programozói tapasztalatokkal rendel- 
kezünk a Python és a Zope területén, szinte biztosan fel tudjuk 
használni a CMF-rendszert saját típusaink Zope-termék alakú 
létrehozásához, velük pedig lenyűgöző és érdekes oldalakat 
készíthetünk magunknak és ügyfeleink számára. Ugyanakkor, 
amíg a típuskészítő rendszer nem lesz egy kicsit jobban 
érthető, a Zope-közösségen kívül a CMF nem fogja az őt meg- 
illető figyelmet megkapni. A Zope-termékek létrehozása ma 
már nem tűnik olyan fekete mágiának, mint korábban, és 
várhatóan a jövőben a CME-típusok készítésére is ugyanilyen 
szemmel tekintünk majd. 

A következő hónapban hirtelen fordulatot veszünk, és 

egy másik nyílt forrású CMS rendszert vizsgálunk meg: 

a Bricolage-t. A Bricolage, ami Mason-, mod. per1- és 
PostgreSOL-alapokra épül, igen szép területet hasított ki 
magának az elmúlt években, és egyre jelentősebb résztvevője 

a nyílt forrású CMS-közösségnek. 
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Rewven M. Lerner (2 http:Awww.lerner.co.il/atf) 
Nyílt forrású programokra, valamint web- és adat- 
bázis-alkalmazásokra szakosodott tanácsadó. 
Könyve, a Core Perl, 2002 januárjában jelent meg 
a Prentice Hall gondozásában. Reuven feleségével 
és lányaival Izraelben, Modrin-ben él. 





A Zope CMF honlapja a 5 http://emf.zope.org 
Már a honlapon sem tudtam egyszerűen eligazodni, 
ráadásul semmilyen jó minőségű, hasznos útmutatót 
sem találtam CMF-témában. 

A legjobb, CMF-típusokról szóló bemutatkozó jellegű 
írást nem a CMF-oldalon, hanem a Plone oldalán, a 

2 http:/Avww.plone.org címen találtam. Például a 

2 http://Plone.org/documentation/CMF IypesBook/ 
backtalk book view címen fellelhetjük a CMF lypes 
Book írást, amely Jól olvasható és számos példát 
tartalmaz. A The Plone Book a. fejezete szintén tartalmaz 
néhány hasznos útmutatót a CMF-típusokról. Ezt a 

2 http://pblone.org/documentation/book/8 címen találjuk. 
Mint mindig, a 3 http:/Avww.zopelabs.com címen 
található a ZopeLabs szép számú példakódja és 
minibemutatója. 


A hálózat rejtett zugai 
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Hálózatunk legsötétebb sarkainak megvilágításához Marcel 
a hálózatmegfigyelő eszközökből állított össze egy különleges menüt. 


em, Francois, ennek a szimatolónak semmi köze a 
borhoz. A bor az a terület, ahol az emberi orr bármi- 
lyen programnál jobban teljesít, függetlenül attól, 
hogy milyen okos a programozó. Őszintén szólva, mon ami, 

a borkóstolás — természetesen minőségellenőrzési célzattal — 
olyan feladat, amit nem szívesen automatizálnék. Azoknak a 
szimatolóknak, amikkel a Linuxszal való kotyvasztás közben 
találkozhatunk, más a rendeltetése. 

Nézz csak ide, mon ami! Figyeld meg, hogy a sávszélességünk 
mekkora része van használatban itt és itt. Kíváncsi vagy, hogy 
ezek a kapcsolatok mekkora sávszélességeket jelentenek? 
Francois, miért nem ide figyelsz? Á, megérkeztek a vendé- 
geink! Miért nem szóltál? 

Bonsoir, mes amis! Örömmel üdvözöllek titeket ismét Chez 
Marcelnél, a kitűnő Linux-konyha, a világ legjobb borai és 

a nyílt forrású dolgok iránt érzett általános szeretet házában. 
Üljetek csak le, és helyezzétek magatokat kényelembe! Mielőtt 
megérkeztetek, éppen arról beszéltem Francois-nak, hogy 
mennyi rejtett adat áramlik keresztül egy átlagos hálózaton. 
Ha már a rejtett élvezeteknél tartunk, Francois, kérlek, siess 

a borospincébe, irány a nyugati szárny, és hozd fel az 1995-ös 
Rioja Imperial Gran Reservát. Ez a spanyol vörös egy tökéletes 
hálózatos bor, nemde? 

Éppen azt ecseteltem hűséges pincéremnek, hogy egy átlagos há- 
lózaton mennyi minden történik, és sokan teljesen megfeledkez- 
nek azokról a kapcsolatokról, amiket korábban ők kezdeményez- 
tek. A működő kapcsolataink ellenőrzésére szolgáló legegysze- 
rűbb eszköz, a Netstat minden Linux-rendszercsomagban megta- 
lálható. A -a és -p kapcsoló segítségével rendszerünk szinte 
összes nyitott hálózati kapcsolata (vagy kapuja) feltérképezhető, 
és azt is megtudhatjuk, hogy melyiket melyik program használja. 
Figyeljük meg, mi történik akkor, amikor a programot futtatom. 
Használni fogom a -n kapcsolót is, ami a Netstatot arra utasítja, 
hogy ne habozzon az IP-címeket szimbolikus címekké alakítani. 
Ez egy kicsit gyorsítja a program futását, mert így nem hajt 
végre névfeloldást. Az eredmény egy meglehetősen hosszú lista 
is lehet, ezért a kimenetet a more-ra irányítottam, lásd a listánkon. 
Á, Francois, megérkeztél a borral, nagyszerű. Kérlek, tölts a 
vendégeinknek! A lent látható lista nem teljes, de az általam 
kapott is hiányos. Ennek oka, hogy az álcázott (masgueraded) 
kapcsolatok IP-táblái a Netstat számára nem láthatóak; ez az 
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fictive Connections according to /proc/net/ip. conntrack 
Source Address Remote Address 
Name Resolution 
199.243.101.42:33288 
Wuww )? clouso.risg.gc.ca 
192.168.22.252:33960 
UNRESOLYEDI ? herc. jabber.org 
192.168.22.252:36911 192.168.22.10:110 
UNRESOLYED! ? website.salmar . com 
192.168.22.252:36908 192.168.22.10:22 
UNRESOLYED! ? website.salmar . com 
199.243.101.42:33288 198.6.1.83:53 
www 2? autho3.ns.uu net 
192.168.22.252:33107 
UNRESOLYEDI! ? herc. jabber.org 
192.168.22.100:53721 208.245.212.108:5222 
ateway.salmar.com 2? herc. jabber.org 
192.168.22.100:631 192.168.22.255:631 

gateway. salmar. com 2? UNRESOLYED! 

199.243.101.42:33288 192.100.59.110:53 
www 2? buchu.arin.net 
192.168.22.252:34797 208.245.212.108:5222 

M  UNRESOLYEDI! ? herc. jabber.org 
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1. kép A conntrack figyelőprogram megjeleníti az álcázott kapcsolatokat 


Service 
192.26.210.1:53 domain 
208.245.212.108:5222 jabber—clientESTABLISH 
pop3 TIME WAIT 
ssh ESTABLISHE 
domain 
208.245.212.108:5222 jabber—clientESTABLISH 
jabber—clientESTABLISH 
ipp-ipp 

domain 


jabber—eclientESTÁABLISH 


tcp 
ED 


adat egy másik helyen található, mégpedig a 

/proc/net/ip conntrack fájlban. A PID a kapcsolatot használó 
program folyamatazonosítója. Éppenséggel kiadhatunk egy 
cat parancsot a /proc/net/ip conntrack fájlra vonatkozóan, 

de az eredmény nem lesz egy szemnyugtató olvasmány. 
Pillantsunk az alábbi példára (a kimenet egyetlen burkolt sor): 


tGD 6 431253 ESTABLISHED 

sea GSeT92 . L65.22.9" AötslS2. 1686: 28.10 
5sport-34212 dport-22 src-192.168.22.10 
edett sel92z 168.22.0. BDOLUSZZ 
—5dport-34212 [ASSURED] use-1i 


Patrick Lagacé is nyilván nehezen olvashatónak találta ezt 

a szöveget. Az ő Conntrack-néző parancsfájlja a 

9 http:/cv.intellos.net címen érhető el. Mivel egy Perl nyelvű 
parancsfájlról van szó, a letöltés után a jogosultságok meg- 
változtatásával egyszerűen tegyük futtathatóvá a fájlt, és adjuk 
ki a következő parancsot: 


chmod --x conntrack-viewer.pl 
. /contrack-viewer.pl 


A kimenet alapértelmezésben az összes kapcsolatot megmu- 
tatja, az álcázottakat is beleértve. A -m kapcsolóval korlátoz- 


(servers amcd estaloilislaedi) 


Proto  Recv-O0  §Send-O Local Adress Foregin AdresSs State PID/Program name 
üejb 0 20 192 .168.22.100 922 MŰSZERT SAR FETT (00 (10 ESTI (0 KAL GRRR ESTE MTE S TETTE DSE ZEStelateli 

Tej 0 0 192 .168.22.100 922 MIKE ZNI ÉT SZART (0) KÉSIK 0 MLS SNS MTE SETÉT SON SZ amel 

TEjö 0 0 192. 168.22.100953 9.0.0.097 NNTESTtSátEANI 6122/named 

so 0 0 ÜLSZ TESATO ETO 8 (0 TÉS0 TÉK Fés ILLILSTEIENNI 6122/named 

Neo 0 0 (JOEL KEK ÉSÉ MENÉS OTTO ÉSE ILL STETENNI MSZAG ÁÁ laitettso tel 

Hej 0 0 (0 ESOKER 0 (ÉSE 90.005 ILILSTEIENNI 
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3. kép A Driftnet munkában: minden képetek hozzám tartozik! 


hatjuk a kimenetet az álcázott kapcsolatokra, az ellenkező 
hatás (az álcázott kapcsolatok elrejtése) a -d kapcsolóval érhető 
el. Vessünk egy pillantást az 1. képre, amelyen a program 
kimeneti képe látható. 

Alexander Neptun Nnetstat nevű programja tetszetős külsejű 
grafikus segédprogram a működő hálózati kapcsolatok, útvá- 
lasztó táblázatok és egyebek megjelenítésére. Saját legfrissebb 
példányunkat a 3 http:/www.aneptun.de/linux/Nnetstat 
címről tölthetjük le. A program alapjában véve egy Perl-pa- 
rancsfájl, így telepítésre nincs is szükség, elég lehetőséget 
teremteni arra, hogy a Nnetstat.pl fájl futtatható legyen. Mint 
kiderül, a Nnetstat futtatásához szükség van még a Gtk.pm 
modulkönyvtárakra, és míg a Perl minden bizonnyal a rend- 
szerünkön van már, ez a modul valószínűleg nincs. A beszerzés 
legegyszerűbb módja a Perl CPAN adattárról való letöltés, és 

a telepítő parancssor is egész barátságos: 

perl -MCPAN -e "install Gtk" 

Ha ez az első alkalom, amikor ilyen módon telepítünk Perl-mo- 
dulokat, először keresztül kell jutnunk egy kis kérdés-felelet 
részen. Menjünk végig rajta, és fogadjuk el a felajánlott érté- 
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interface: ethő 
load averages: 1.2ő 477.6k 181.,7k bps 


bpz z desc 
SZ2.Ő 0£Z tcp barogue: d2228 (€-2 websiter:szh 
tcp barogue: 42280 €-2? s002:http 
- 200 GET /branding/style,csz 
795.2k 55£ tep barogue: 42283 €-2? hOd:http: 
L 200 GET /stable/1.,0.3/000. 1 0.3.1 LinuxIlntel install,.tar.gz 
610.9k 42Z tcp gateway: 52379 €-? mirrors:z284 
238.4 0Z udp 192.168.22.255:631 €-? gateway:631 
n udp barogue: 32899 €-2 website:domain 


(New [33 shel No. 2 


4. kép Az azonosított fájlnevek a pktstat megjelenítőjén 





keket — bízzunk a rendszerben. Amit meg kell adnunk, az a 
legközelebbi CPAN-tükrözések címe. Amikor a rendszer fel- 
teszi a kérdést, válasszuk ki a földrészt és az országot, majd 

az elérhető helyi tükrözéseket. Ha ezzel készen vagyunk, a 
Gtk telepítése magától folytatódik. 

A Gtk Perl-modulok telepítése eltart egy darabig. Ialán nem árt 
felhívnom a figyelmet, hogy a telepítés végefelé még egy teszt- 
sorozat lefut. Ne lepődjünk meg, ha egy grafikus ablak jelenik 
meg a képernyőn, azt kérve, hogy a csomaggal kapcsolatos 
grafikus varázslatok kipróbálása céljából kattintsunk a Run 
feliratra. Amikor elégedettek vagyunk az eredménnyel, a próba 
befejezéséhez kattintsunk a Close gombra, és végezzük el a 
telepítésből hátralévő részt. 

Ha igazán rémisztő — vagy szórakoztató, ez nézőpont kérdése — 
módon szeretnénk látni, hogy pontosan mi folyik keresztül 

a rendszerünkön, használjuk a Driftnetet. Már maga a név 
(vonóháló) elég ahhoz, hogy az embernek a hideg kezdjen 
futkosni a hátán. Röviden a Driftnet figyeli a kiválasztott csato- 
lófelületen áthaladó kép- vagy videofájlokat (csak az MPEG 
típusúakat), és a talált képeket megjeleníti. Hogy ez a felfedés 
a rendszergazda számára félelmetesebb-e, hiszen kiderül szá- 
mára, hogy a felhasználók miket néznek, esetleg maguknak a 
felhasználóknak, az több tényezőtől függ. A képgyűjtemény 
teljesen válogatás nélküli, semmilyen módon nem utal egy 
valóságos felhasználóra. 

Saját példányunk beszerzéséhez keressük fel Chris Lightfoot 
honlapját a 3 http:/www.ex-parrot.com/-—chris/driftnet címen, 
és töltsük le a forráskódot. Mielőtt a köztetek lévő szellemidé- 
zők megkérdeznék - amikor utoljára ellenőriztem, a honlap 
még nem szűnt meg és nem is költözött melegebb éghajlatra. 
A Driftnet lefordításához szükség van néhány programkönyv- 
tárra, ezek közül a legjelentősebb a libungíif, a libjpeg és a 
libcap. Ha még nem telepítettük őket, a hivatkozások a cikk 
végén, a Kapcsolódó címek között megtalálhatók, de először 

a rendszercsomag lemezein érdemes keresnünk. A csomag 
lefordítása ettől kezdve egy egyszerű tarcsomag-kibontás és 

a make futtatása a forráskód könyvtárában. Ezután már futtat- 
hatjuk is a kicsomagolt programot a könyvtárból, vagy átmá- 
solhatjuk egy megfelelőbb helyre: 

ari ttnet -i attú 

Mivel a Driftnet futtatásához a csatolófelületet vegyes módra 
kell állítani, a futtatásához rendszergazdai jogosultságra van 
szükség. A 3. képen a Driftnet működés közben látható. 
Kétségtelen, hogy a hálózatunkon keringő képek nézegetése 
jó szórakozás, ha nem törődünk a folyamat sávszélességigé- 
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5. kép Az lIPTraf alapértelmezett megfigyelőablaka 


nyével. De milyen egyéb érdekes dolgok mozognak ezekben 

a vezetékekben? Világhálós kérések, fájlletöltések, elektronikus 
levelek, üzenetváltások és még egy csomó más. A legtöbb háló- 
zatfigyelő program - a Netstatot is beleértve — megmutatja a 
működő kapcsolatokat, de a következő kérdés az, hogy ezek 
pontosan mekkora forgalmat képviselnek. 

David Leonard írt egy ncurses-alapú programot, amely a 
pktstat nevet viseli 

(2 http:/wwwiitee.ug.edu.au/-leonard/personal/software/ 
pktstat), és igen jó munkát végez az egyes kapcsolatok által 
lefoglalt sávszélesség bemutatásának terén. Az üzemben töltött 
idő formájában tárolja a mindenkori hálózatterhelési értéket, 
de nem a futtatási sor folyamatainak, hanem az átviteli sebes- 
ség nyomon követésével. A többi programtól az a képessége 
különbözteti meg, hogy a hálózatunkon lévő ügyfélgépekről 
letöltött vagy a webkiszolgálón áthaladó adatcsomagokhoz 
rendelt fájlneveket meg tudja jeleníteni. A pktstat fordítása a 
forráskód kicsomagolásából, a megfelelő könyvtárra való 
váltásból és a make parancs futtatásából áll: 


tar -xzvíií pktstat-1./.2a4.tar.gz 
cd pktstat-1.7.2ag 

make 
sú -c. "make iústall" 

A program futtatásakor a -i kapcsolóval adhatjuk meg azt 
a csatolót, amelyiknek a forgalmát vizsgálni szeretnénk: 
pktstat -i ethi 

Ekkor egy, a 4. képen láthatóhoz hasonló ablak jelenik meg. 
Mint látható, elkezdtem letölteni a legfrissebb Openoffice.org- 
csomagot. A tényleges fájlnév a kapcsolat adatai alatt jelenik 
meg, ugyanez érvényes a HTIP-webkérésekre. Nemcsak a 
letöltés alatt álló fájl címe látszik, hanem a fájl neve is, legyen 
akár egy HIML-oldal vagy egy kép. 

Ha már a hálózati forgalomról esett szó, és ha egyszerűen arra 
akarjuk fáradozásainkat összpontosítani, hogy éppen hol és 
mire használják a hálózatunkat, ennek kiderítésére a mai menü 
legutolsó fogásaként felszolgált IPIraf a legmegfelelőbb. 
Szerény konyhafőnökötök egyik kedvenc IP-forgalomfigyelő 
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segédprogramja, amihez időről időre mindig visszatér, az 
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IPIraf. Ez egy ncurses alapú program, ami megjeleníti az 
IP-forgalmat, a csomagok és bájtok számát (beleértve a nem IÍP- 
csomagokat is), az UDP-forgalmat, a bejövő és kimenő adatok 
mennyiségét és még sok egyebet. Az IPIraf az a csomag, 
amelynek mindenkinél kéznél kell lennie, akit egy hálózat 
felügyeletével bíztak meg. 

Látogassunk el Gerard Paul Java-honlapjára 

(2 http:/iptraf.seul.org), és töltsünk le egy IPIraf-példányt 
magunknak. Csomagoljuk ki a tar és gzip programokkal 
becsomagolt fájlt, lépjünk a könyvtárba, és a program lefordítá- 
sához futtassuk a Setup-ot. A telepítési folyamat a bináris 
állomány /usr/local/bin könyvtárba való másolásával fejeződik 
be. Az IPIraf futtatásához gépeljük be az iptraf parancsot, 
nyomjunk ENTER-t, és már sínen is vagyunk (az 5. kép egy 
működő IPIraf-folyamatot szemléltet). 

Miközben az IPIraf összegyűjti és megjeleníti az adatokat, a 
képernyő nagyon hamar megtelhet. Érdemes nagyobb, például 
80 x40 méretű X-terminálon futtatni a programot. Az Esc gomb 
megnyomásával visszatérhetünk a pillanatnyi nézetből vagy 
folyamatból. Innen megváltoztathatjuk a beállításokat, szűrőket 
adhatunk hozzá vagy távolíthatunk el, majd folytathatjuk az 
adatgyűjtést. Az IPlraf különböző nézeteket kínál többek között 
az alapértelmezett állomások közötti forgalomról, a csatoló 
forgalmi kimutatásának alap- és részletezett adatairól, egyéb 
fizikai statisztikákról és a csomagméret-hibákról. Ne tévesszen 
meg a program látszólagos egyszerűsége. Az IPTraf elég rugal- 
mas ahhoz, hogy az ÍP-megfigyelés számos igényét kielégítse. 
Nos, mes amis, a záróra rohamosan közeledik. Mialatt Francois 
újratölti a poharaitokat, én annak a reményemnek adok 
hangot, hogy amikor elmentek, pontos képpel fogtok rendel- 
kezni arról, hogy mi történik a hálózataitokon. A jó rendszer- 
gazdák tudják, hogy mi folyik a hálózatukon, ám emellett azt 
is tudják, hogy mit nem szabad észrevenniük. Ezzel emelem 
poharamat rátok, mes amis. A votre santé! 

Bon appétit! 


Linux Journal 2003. augusztus, 112. szám 


Marcel Gagné (mggagneosalmar.com) 
Mississaguában, Ontario államban él. 

Ő a szerzője a Kiskapu kiadásában tavaly szep- 
temberben megjelent Linux-rendszerfelügyelet 
(ISBN 96-9301-40) című könyvnek (jelenleg is 
egy könyvön dolgozik). 








Conntrack nézőke 5 http://cv.intellos.net 
Driftnet 8 http:/Avww.ex-parrot.com/-— chris/driftnet 

IPIraf 8 http://ptraf.seul.org 

Libjpeg (independent JPEG Group) 3 http:/Avww.ijg.org 
Libpcap (csomagbefogó programkönyvtár) 

2 http:/Avww.tcpdump. org 

Nnetstat 3 http:/Avww.aneptun.de/linux/Nnetstat 

Marcel borlapja 8 http:/Avwvw.marcelgagne.comAwine.html 
Libungif 5 http://prtr-13.ucsc.edu/-badger/software/libungif 


Pktstat 
5 http:/Avww.itee.ug.edu.au/-leonard/personal/ 
software//pktstat 
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A jól bevált wxWindows a most készülő Chandler 


csoportmunkaprogram eszközkészlete. 


többfelületes fejlesztés az utóbbi években minden- 
napos kifejezéssé vált — Redmond bugyraiban épp- 
úgy, mint a nyílt forrású kezdeményezések háza 
táján. Használata szinte mindig a Java, .NET, a V vagy a Ot 
körül forog, de ne feledkezzünk meg a wxWindowsról sem. 
Akár MFC-kódot akarunk Linuxra átültetni, akár egyszerűen 
csak a lehető legszélesebb közönség számára akarunk egy 
programot elérhetővé tenni, a wxWindows megállja a helyét. 
Furcsa módon úgy tűnik, hogy még nem sokan hallottak róla, 
de írásunk remélhetőleg segít abban, hogy szélesebb körben 
is megismerjék. 

Miért választanánk a wxWindowst a fenti fejlesztőeszközök 
helyett? Jogos a kérdés, és minden egyes eszköz esetében más 
és más a válasz. 


Összehasonlítás más eszközökkel 

Bár a KDE-programok készítéséhez a Ot a szabványos eszköz, 
a wxWindows szintén használható. A Ot windowsos változata 
jogdíjas programok készítéséhez nem használható fel szaba- 
don, de a wxWindows igen, és a Ot az eseménykezelő rend- 
szerhez különleges előfeldolgozót igényel. 

A Microsoft .NET és az Ximian Mono rendszere éppúgy, mint 
a Java, nem annyira eszközkészlet, inkább technológia. Ezek 

a megoldások újabb réteget adnak a programokhoz, ami a 
teljesítmény rovására mehet. Erről a kérdésről a , fejlesztési idő 
vagy futásidő" ellentét alapján is vitát lehetne nyitni, amit a 
program életciklusa befolyásol a leginkább. Ahelyett, hogy 
belebonyolódunk a kifejezések körüli csatározásokba, csak 
annyit mondunk: ,mindenki másképp csinálja" . 

A V pedig egyszerűen nem olyan rugalmas, mint a wxWin- 
dows; nem támogat annyi fordítót. Még mielőtt a wxWindowst 
ezekkel a többfelületes fejlesztőeszközökkel igazán összevet- 
nénk, fontos megemlítenünk, hogy a wxWindowsnak minden- 
féle összehasonlítás nélkül is megvannak a maga erősségei. 

A wxWindowszal megkapjuk a nyílt forrás megszokott előnyeit 
— jogdíj fizetése nélkül felhasználható, szabadon módosítható, 
továbbá megszabadulunk attól a kockázattól, hogy a terjesztő 
cég megszűnik (vagy olyan módon frissíti a programkönyv- 
tárait vagy a fejlesztőeszközeit, hogy kénytelenek legyünk 
megvenni az új változatot). Ezenkívül a programot a legkülön- 
bözőbb operációs rendszereken is szabadon futtathatjuk, 
például Unix/Linux, Windows, Mac OS 9, Mac OS X és OS2 
környezetben. Ráadásul minden rendszeren egységes meg- 
jelenést ad. A wxWindows felhasználási szerződése rugalmas, 
és a Nyílt Forrás Kezdeményezés (Open Source Initiative) 

is jóváhagyta. 

Körülbelül 11 évi fejlesztéssel a háta mögött a wxWindows 
üzembiztos, kiforrott fejlesztői programkönyvtár, amihez a 

2 http:/wxWindows.org honlapon elérhető levelezőlisták 
valós idejű támogatást nyújtanak. A több mint háromszáz 
osztály és ötezer függvény nagyszámú szolgáltatást tesz 
elérhetővé. Ezzel a könyvtárral az MEC programok átültetése 
is egyszerű feladat. 
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wxWindowst használó programok 

Olyan vezető cégek is használják a wxWindowst, mint az 
AMD, az Intel Graphics Lab, a Compag Alpha processzor 
fejlesztőcsoportja, a Netscape és a Lockheed Martin. Az Open 
Source Applications Foundation az új, Chandler névre keresz- 
telt, személyes adatok kezelésére és csoportmunka támogatá- 
sára szolgáló programjában használja (wxPython segítségével). 


TT üntitled - elős Cönfiguration Tool 


File Edit View Build Tools Help 
JÖGH 2 Bt: 


E (I Configuration Property 

a] Reguires CYG 
Reguires CYG 
Reguires CYG 
Reguires CYGF 
Reguires 1 —— 
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Ed Global command prefix CYGPKGOHALOSHOSH77 Unsatisfied 
lab] Global compiler flags CYGPKG.HALOSHOSH77 Unsatisfied 
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Ep Infrastructure CYGBLD. GLOBAL COMMAND P 


Hy eCos kernel sh-elf 


úrren 
tr Dynamic memory allocation current 


sh-elf 


v 


1] 


This option specifies the command prefix used 
when inyoking the build tools, 
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A Helpblocks (3 http:/www.helpblocks.com) programmal 
különböző felületekre készíthetők súgóállományok, és mind 
Windows-, mind Linux-rendszerre a wxWindows könyvtárral 
fejlesztik. Többek között wxWindowsos alkalmazás még a 
Vulcan 3D (modellezőprogram bányaipari felhasználásra, de 
még több is ennél), a Scilech Display Doctor programja, az 
Intuitive MX (egy többsávos hangkeverő, ami 3D-ben jeleníti 
meg a keverési folyamatot -— az Intuitive Works fejleszti), 
valamint a Ground Control Station a Geneva Aerospace-től. 
Akár a te programod lehet a következő a listán! 


Linuxos fejlesztés wxWindowszal 

Szükségünk lesz a gcc-re, és olyan eszközöket használhatunk, 
mint a gdb, a ddd, az Emacs, valamint olyan egységes fejlesz- 
tőkörnyezetet, mint az Anjuta. Ha Windowsra is fordítunk, egy 
keresztfordítóra is szükség lehet. Legfőképpen pedig szüksé- 
günk lesz magára a wxWindows könyvtárra, ami szintén meg- 
található a wxWindows-honlapon vagy megrendelhető CD-n 
is. A cikk írásának idején a legfrissebb változat a 2.4.0-s volt. 
(jelenleg a legfrissebb megbízható változat a 2.4.1-es, ami 
megtalalható az 51. CD Magazin/wxWindows könytárában). 
Sokunk jó szokásaival ellentétben nem árt elolvasni a csomag- 
ban található leírás linuxos fejlesztésre vonatkozó részét. 

Nem árt feliratkozni a wx-user levelezési listára sem 

(a 5 http:/wxWindows.org lapon a Support alatt találjuk), 
hátha nem megy minden könnyűszerrel. Legokosabb, ha a 
kérdéseinkre rákeresünk az archívumban, hátha föltette már 
őket más is. 

Maga a könyvtár több mint hetven példaprogramot tartalmaz, 


Egy wxApp osztály létrehozása 


VAYG WOK a hü" 
"moridktámketatogenti 


ame lluee 
1 ige üde 


/—-j alkalmazó ze Nee 
// meghatározása 
class MyApp foGoNÉ ke iNyezatojomái 
fojboNlnkse 
// kezdőérték-adás 
ZAL áai tos b KEHÁT ko (0 ro ALL rnNTTan et Ttetl ti) Hós 


Ja 


//EÚjökerettíipüs medhatározása rő keretként 
class MyFrame public wxFrame ( 
fojólolliíss 
MyFrame(const wxStringg title, 
comnst WE BDOLMNták 10S ; 
const Wdizet SÍiZz6; 
HKOTaGáás öz ese YVEG[D TEKTTESZ TTV NTNNTEENESHTTR SZÁNT NTEEEÉRSSta TAVA ls 


// Eseménykezelők (nem virtuális!) 
void OnOuit (wxCommandEventg event) ; 
MoNcMOA o otekíNe e €onmáenmelttzernee ken zenet 


private: 


// Eseménytábla bevezetése 
DEETANRE ENVZTENNIEL ANBILJE ( ) 
J; 


777 alkalmazásobjektum létrehozása 
IMPLEMENT APP(MyApp) 


755 Mádi A66 " megtelője 
ora GANYI Zoo ESSEK TnKT atát) 


A 

// Fő alkalmazásablak létrehozása 

MyFrame "Íírame - 

new MyFrame( T("Example" ), 

wRkoimamc(50, 50). waSize(450. 

SZOA hő 

Írame-:-Show( IRUE) ; 

ele iutók ae it U ÁEH 
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amelyek szinte mindent bemutatnak, amire a könyvtárat 
valaha is eszünkbe juthat használni — valószínűleg ez a legjobb 
leírás, mert így működő programokkal kísérletezgetve figyel- 
hetjük meg, hogyan is rakták őket össze. Ha a könyvtárat 
beszereztük, és a megszokott fejlesztőeszközeinkkel már 
kezelni tudjuk, kezdődhet a programozás. 


Egy-két példa 

Egyszerű alkalmazásosztályt létrehozni nem nehéz. 

Listánkon egy wxApp osztály létrehozására láthatunk példát. 
Amint látható, könnyen hozhatunk létre új wxWindows alkal- 
mazást, és az MFC-t közelebbről ismerő olvasók talán elgon- 
dolkozva dörzsölik az állukat. Örömmel vehetik tudomásul, 
hogy nincs benne MEC, soha nem is lesz, de az osztályok 
egyszerűen átalakíthatók MFC-ből. Akad benne néhány dolog, 
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ami az MFC-ben nincs, és nem támogatja az OLE-t. 

Listánkon egy üres eseménykezelő is látható, ami olyan esemé- 
nyek kezelését teszi lehetővé, mint az egérkattintás, a billen- 
tyűleütések vagy a saját egyedi események. Ez a kód egy 
eléggé unalmas programot ír le, ami csak csücsül magában és 
meg se mukkan. 

A könyvtár tele van működő példákkal — mintha minden osz- 
tályhoz lenne egy példadémon, ami bemutatja a működését. 

Az egyik az eseménykezelést bemutató példa, ami Vadim Zeitlin 
munkája. Azért választottam ezt, mert a legtöbb wxWindowszal 
ismerkedő fejlesztőnek gondja akad az eseményekkel - az 
olvasó tehát egy kis előnyre tehet szert. Kipróbálásához szükség 
lesz a wxWindows könyvtárra, és ha ez megvan, akkor a teljes 
forráskódja is megtalálható a Samples könyvtárban. 

A honlapon még egy Wikire mutató hivatkozás is fellelhető, 
úgyhogy könnyen elérhető a legfrissebb leírás, és még bele 

is javíthat, akinek hozzáfűznivalója akad. 
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Adjuk meg a fejlesztőknek, ami jár! 

A több ezer hozzájáruló mellett a fejlesztőcsapat magja külön 
említést és köszönetet érdemel: 

e Julian Smart 5 http:/www.anthemion.co.uk 

e. Robin Dunn 2 http:/www.python.org 

e. Vadim Zeitlin 5 http://wwwitt-solutions.com 

e Stefan Csomor 5 http:/www.advanced.ch 

e — Vaclav Slavik 3 http:/sourceforge.net/users/vaclavslavik 
e Robert Roebling 5 http:/www.roebling.de 


Ők a xw-user levelezőlistán gyakran napi, ha nem óránkénti 
rendszerességgel nyújtanak segítséget a wxWindows könyvtár 
felhasználóinak. 


A wxWindows jövője 

A 2.4.0-s változat kiadását követően a fejlesztőcsapat megadta 
azoknak a szolgáltatásoknak a listáját, amiket a 3.0-s változat- 
ban látni szeretnének. A támogatott felületek köre folyama- 
tosan bővül, ez a következő kiadásban sem lesz másképp. 

Az egyik új felület Marco Cavallini és Robert Roebling munká- 
jának köszönhetően feltehetőleg a Windows CE lesz. 

Készül a Winelib támogatás is a Winelib-csapat gondozásában, 
Julian Smart és Stefan Csomor pedig az MFC-ről wxWindows- 
ra átültetést segítő jogdíjas eszközöket fejleszti. 

Mivel egyre több cég használ Linuxot, MFC-kódjukat szeretnék 
Linuxra átültetni, és ennek egyik legegyszerűbb eszköze a 
wxWindows könyvtár. Már csak a kedvező költségekek miatt 

is megéri. Az átállással járó fejlesztési gondokat a könyvtár 
egyszerű felépítése a lehető legkevesebbre csökkenti, ezért a 
Windowsról Linuxra történő átállást tervező cégek kódjuk egy- 
szerű átvitelére számíthatnak. Még wxNET felület fejlesztése 

is folyamatban van. 

Lehet, hogy neked is van mit hozzátenned a wxWindowszal 
megvalósított programok hosszú sorához. A wxWindows 
programokról naprakész lista található a 

2 http:/wxWindows.org honlapon. 
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Taran Rampersadt (3 http://KnowProSE.com) 

14 éves tapasztalattal rendelkező programfejlesztő; 
jelenleg tanácsadással és fejlesztéssel foglalkozik. 

J Trinidad és lobagoról ír. Részt vesz a helyi számító- 
gépes társaságokban, és segít a Caribbean FLOS Kon- 
ferencia (3 http://floscaribbean.org) szervezésében. 
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Webkiszolgáló az asztal alatt 


Avagy hogyan készítsünk tartománynevet dinamikus 
IP-címmel rendelkező kiszolgálónknak. 





kimutatások szerint hazánkban 
az internet-hozzáférés még 
igencsak siralmas állapotban 


van, bár szép lassan javul a helyzet. Ez el- 
sősorban a különböző DSL és kábeltévés 
hozzáférések terjedésének köszönhető. 
Ha egy ilyen csatlakozás végére egy 
linuxos kiszolgáló kerül tűzfallal, felme- 
rülhet az igény, hogy egy kis webkiszol- 
gálót is lehetne üzemeltetni. No nem 
azért, hogy hatalmas forgalmú csomó- 
pontot képezzünk információkban dús- 
káló portálok számára, hanem csak úgy, 
a saját szórakozásunkra, hogy kipró- 
bálhassuk, hogyan is működik egy ilyen. 
Esetleg törzsügyfeleinknek szeretnénk 
zártkörű hozzáférést biztosítani az anya- 
gainkhoz. Egy ilyen weboldal elérésével 
egyetlen gond akad, az, hogy nem 
tudjuk a címét, mivel az IP-cím idő- 
közönként változik. 

Nézzük meg, hogy milyen megoldás 
lehetséges arra, hogy webkiszolgálónkat 
a változó IP-cím ellenére mindig állandó 
tartománynévvel érhessük el. A megol- 
dáshoz egy ingyenes szolgáltatást 
fogunk igénybe venni. 

A weben találhatóak olyan szolgáltatók, 
amelyek ezt a szolgáltatást kínálják, 
ilyen a DYnDNS, a Nolp stb. Most a 
DynDNS-en keresztül mutatjuk be, 
hogyan is működik a dolog. 

Első lépésként látogassunk el a DuJnDNS 
weboldalára. A 5 http:/www.dyndns.org 
oldalon megtaláljuk, amit keresünk. A nyi- 
tóoldalon válasszuk mindjárt a Services 
fület, és a 6. pontban már meg is találtuk 
azt, amire szükségünk van: a Dynamic 
DNS szolgáltatást. 


A Dynamic DNS szolgáltatás 

A dinamikus DNS-oldalra lépve tájékoz- 
tatást kapunk a szolgáltatás mibenlé- 
téről, tehát itt kell majd beállítanunk 

a webkiszolgáló címét. 

Mielőtt bármit tenni tudnánk, be kell 
jegyeztetnünk (registration) egy új 
hozzáférést, így a felhasználónevünkkel 
és jelszavunkkal a későbbiekben is mó- 
dosítani tudjuk a beállításokat, ha az 
szükséges. A hozzáférést az Account 
menü alatt tudjuk bejegyezni. Itt el kell 
fogadnunk a felhasználási feltételeket, 
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meg kell adnunk a felhasználónevet, 
elektronikus levélcímünket és jelsza- 
vunkat. Valós elektronikus levélcímet 
adjunk meg, mert a visszaigazolást erre 
a címre kapjuk meg - enélkül nem 
működik a szolgáltatás. 

Amennyiben az ügyintézési részen 
túlestünk, jöhet az érdemi munka. 





Most a frissen kapott hozzáférésünkkel 
már beléptünk, így a Dynamic DNS cso- 
portban ki tudjuk választani az Add host 
menüt. A New Dynamic Host oldalon 
megadhatjuk a webkiszolgáló nevét, 
például sajatweb vagy homeweb. 

A pont után egy szép nagy listából tar- 
tományt választhatunk a névhez - vá- 
laszthatjuk például a homelinux.net-et, 
így a webkiszolgálónk címe: sajatweb 
sajatweb.homelinux.net lesz. Az ÍP- 
címnél a jelenlegi címünk látható, tehát 
a rendszer új tartománynevünket első- 
ként ehhez a címhez fogja rendelni. 
Ezzel a tartománynév-bejegyzésen túl is 
estünk. Ha a böngészőnkben meghívjuk 
az új címet, máris a saját weblapjainkat 
láthatjuk a cím alatt. Igen ám, de holnap 
más IP-címünk lesz, ezért az oldalak 
nem lesznek elérhetők. 

A feladat egy kis ügyfélprogrammal old- 
ható meg. A Dynamic DNS csoportban a 
Clients menüpont alatt nagyon sok ilyen 
programot találhatunk, ízlésünknek és 


természetesen operációs rendszerünk- 
nek megfelelőt. Válasszuk ki a Unixot 
az operációs rendszerek listájából és a 
leválogatott listából a ddc1ient prog- 
ramot. Ez természetesen csak példa, 
lehet kísérletezgetni, hogy a többi ho- 
gyan működik. A ddcilient telepítése 
nagyon egyszerű: kicsomagolás után be 
kell másolni a /usr/bin könyvtárba, majd 
a beállításfájlt a /etc alá: 


cp ddelient /uüsr/bin 
cp sample-etc ddcAiient.conf 
s /etc/ddclient.conf 


A másolások után már csak a beállítás- 
fájlt kell megfelelően finomhangolni. 
Hívjuk be kedvenc szövegszerkesz- 
tőnkbe, és szerkesszük át a példafájlt. 
Az alábbi sort keressük meg benne: 


tuse-if, iTt2pDDE; 
tvia interfaces 


Vegyük ki a megjegyzést az elejéről, 
majd pár sorral lejjebb a login és 
password sorokat már bejegyzett 
hozzáférésünk adataival töltsük ki. Most 
már csak meg kell adnunk, hogy melyik 
tartományt szeretnénk frissíteni. Pár 
sorral lejjebb, a ttt dyndns . org 
dynamic addresses csoportban az 
alábbi sorokat állítsuk be: 


server-member . dyndns . org, 
protocol -dyndns2 
sajatweb.homelinux.net 


Ha elindítjuk a dáclient programot és 
ezután változik meg az IP-címünk, a 
program a DynDNS kiszolgálóján frissíti 
a bejegyzést, és webkiszolgálónk a 
bejegyzett címen mindig elérhető lesz. 


Ambrits Tamás (lambritsoambrits.hu) 

Nem , fanatikus" Linux-rajongó, de egyre 
több feladat megoldására alkalmazza nagy 
megelégedéssel. 


Orbán Zsolt (orbixomailbox.hu) 
Igazi Linux-, de inkább Deblan-megszállott. 
Minden érdekli, ami LInUX. 


